You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@hermes.si> on 2000/08/05 03:52:26 UTC
Yet another newbie
Hello everybody,
My name is Branko Čibej (that's /Ccaron ibej for those without latin-2,
pronounced Chee-bey). I've been programming for about 15 years now,
although for more than half that time It was more of a hobby, not a
"real" job. I've made a few contributions to open source projects (a few
bits in Samba and GCC) and I'm an "active lurker" on the GCC mailing
lists, but I haven't really participated in an open source project
otherwise.
More to the point, for four years (ending about a year ago), I worked on
a project that built a file server on top of a proprietary configuration
management system. This gave me a few insights into the problems of CM
system design, and incidentally---since our source was CVS-controlled)---
into the strengths and weaknesses of CVS.
(In fact, lately I've been playing around with ideas and jotting down
designs for a CVS replacement. Good job you beat me to it, or it would
probably never have got off the ground, like a lot of my meta-projects :-)
Anyway, I hope I can contribute in some small way to Subversion. For now,
I'll take up Mr. Fogel's challenge and dig into the Vdelta/VCDIFF library.
It looks like an interesting problem with a lot of potential for generating
some nice code and the required percentage of horrible bugs.
Oh, yes: I'll be working on Solaris 2.6 initially, but I use HP-UX 10.20,
AIX 4.3, Linux and Win NT/2000, so I'll be able to do some cross-platform
testing.
Brane
(no, not pronounced "brain")
P.S.: O.K., now that I've introduced myself and volunteered to do
something, I guess I'm allowed to gripe a bit, too :-)
1) The HACKING file says:
* Signify internal variables by two underscores after the prefix.
That is, when a symbol must (for technical reasons) reside in the
global namespace despite not being part of a published interface,
then use two underscores following the module prefix. For
example:
svn_fs_get_ver_prop () /* Part of published API. */
svn_fs__parse_props () /* For internal use only. */
That's fine iff we can guarantee that no symbol containing two consecutive
underscores will ever be seen by a C++ compiler, a guarantee I think we
can't safely make. Quoting from the C++ standard, sec 7.4.3.1.2 para 1:
-- Each name that contains a double underscore (__) or
begins with an underscore followed by an uppercase
letter (2.11) is reserved to the implementation for any
use.
IMHO we should find some other way to name private symbols. Perhaps a
different prefix (e.g., svnp_) would be better for that purpose.
2) This is from subversion/libsvn_subr/svn_parse.c:
apr_status_t
svn__my_readline (apr_file_t *FILE, svn_string_t *line, apr_pool_t *pool)
^^^^
Hmmm... and it indirectly includes <stdio.h>, too ...
3) Oh, yes: something seems to be wrong with the CVS repository. I get
expat_lite twice on checkout, and conflict warnings about .cvsignore,
even though I haven't modified anything. Perhaps it's due to an empty
"D" line I get at the end of expat-lite/CVS/Entries, which is really
weird. I'm using CVS 1.10.3; should I upgrade that?
--
Branko Čibej <br...@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49 fax: (+386 1) 586 52 70
Re: Yet another newbie
Posted by Greg Stein <gs...@lyra.org>.
We don't plan to use any leading underscores. External/visible symbols will
have one of two forms:
rettype svn_public_function(...)
rettype svn__private_function(...)
And we'll use static functions whereever possible:
static rettype some_function(...)
Cheers,
-g
On Wed, Aug 09, 2000 at 07:57:46AM -0400, Jonathan S. Shapiro wrote:
> The ANSI C and C++ specifications both reserve names beginning with
> underscores for the exclusive use of the runtime system. Such names should
> definitely be avoided.
>
> > According to this snippet from the C++ spec., it's *possible* that names
> > with double underscores may conflict with symbols that are part of a C++
> > compiler's implementation. Different syntactic sugar should probably be
> > adopted for distinguishing between the SVN internal and external API to
> > avoid the possibility of this compiler symbol name conflict.
>
--
Greg Stein, http://www.lyra.org/
Re: Yet another newbie
Posted by "Jonathan S. Shapiro" <sh...@eros-os.org>.
The ANSI C and C++ specifications both reserve names beginning with
underscores for the exclusive use of the runtime system. Such names should
definitely be avoided.
> According to this snippet from the C++ spec., it's *possible* that names
> with double underscores may conflict with symbols that are part of a C++
> compiler's implementation. Different syntactic sugar should probably be
> adopted for distinguishing between the SVN internal and external API to
> avoid the possibility of this compiler symbol name conflict.
Re: Yet another newbie
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Karl Fogel wrote:
> [snip]
> > 1) The HACKING file says:
> >
> > * Signify internal variables by two underscores after the prefix.
> > That is, when a symbol must (for technical reasons) reside in the
> > global namespace despite not being part of a published interface,
> > then use two underscores following the module prefix. For
> > example:
> >
> > svn_fs_get_ver_prop () /* Part of published API. */
> > svn_fs__parse_props () /* For internal use only. */
> >
> > That's fine iff we can guarantee that no symbol containing two consecutive
> > underscores will ever be seen by a C++ compiler, a guarantee I think we
> > can't safely make. Quoting from the C++ standard, sec 7.4.3.1.2 para 1:
> >
> > -- Each name that contains a double underscore (__) or
> > begins with an underscore followed by an uppercase
> > letter (2.11) is reserved to the implementation for any
> > use.
> >
> > IMHO we should find some other way to name private symbols. Perhaps a
> > different prefix (e.g., svnp_) would be better for that purpose.
>
> The two underscores are not about preventing name conflicts, they're
> about reminding humans that a given object is not part of the
> published interface, despite its appearance in a public place.
According to this snippet from the C++ spec., it's *possible* that names
with double underscores may conflict with symbols that are part of a C++
compiler's implementation. Different syntactic sugar should probably be
adopted for distinguishing between the SVN internal and external API to
avoid the possibility of this compiler symbol name conflict.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Yet another newbie
Posted by Branko Čibej <br...@hermes.si>.
Karl Fogel wrote:
>
> Branko =?iso-8859-2?Q?=C8ibej?= <br...@hermes.si> writes:
> > 3) Oh, yes: something seems to be wrong with the CVS repository. I get
> > expat_lite twice on checkout, and conflict warnings about .cvsignore,
> > even though I haven't modified anything. Perhaps it's due to an empty
> > "D" line I get at the end of expat-lite/CVS/Entries, which is really
> > weird. I'm using CVS 1.10.3; should I upgrade that?
>
> Yes, upgrade and try again; if you still have the problem, please let
> us know.
Upgrading to CVS 1.10.8 makes the problem go away. Thanks.
(BTW, it might be a good idea if this was noted on the web pages.)
Brane
--
Branko Čibej <br...@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49 fax: (+386 1) 586 52 70
Re: Yet another newbie
Posted by Karl Fogel <kf...@galois.collab.net>.
Branko =?iso-8859-2?Q?=C8ibej?= <br...@hermes.si> writes:
> Anyway, I hope I can contribute in some small way to Subversion. For now,
> I'll take up Mr. Fogel's challenge and dig into the Vdelta/VCDIFF library.
> It looks like an interesting problem with a lot of potential for generating
> some nice code and the required percentage of horrible bugs.
Bravo! Thanks.
> 1) The HACKING file says:
>
> * Signify internal variables by two underscores after the prefix.
> That is, when a symbol must (for technical reasons) reside in the
> global namespace despite not being part of a published interface,
> then use two underscores following the module prefix. For
> example:
>
> svn_fs_get_ver_prop () /* Part of published API. */
> svn_fs__parse_props () /* For internal use only. */
>
> That's fine iff we can guarantee that no symbol containing two consecutive
> underscores will ever be seen by a C++ compiler, a guarantee I think we
> can't safely make. Quoting from the C++ standard, sec 7.4.3.1.2 para 1:
>
> -- Each name that contains a double underscore (__) or
> begins with an underscore followed by an uppercase
> letter (2.11) is reserved to the implementation for any
> use.
>
> IMHO we should find some other way to name private symbols. Perhaps a
> different prefix (e.g., svnp_) would be better for that purpose.
The two underscores are not about preventing name conflicts, they're
about reminding humans that a given object is not part of the
published interface, despite its appearance in a public place.
> 2) This is from subversion/libsvn_subr/svn_parse.c:
>
> apr_status_t
> svn__my_readline (apr_file_t *FILE, svn_string_t *line, apr_pool_t *pool)
> ^^^^
>
> Hmmm... and it indirectly includes <stdio.h>, too ...
Agree, will fix.
> 3) Oh, yes: something seems to be wrong with the CVS repository. I get
> expat_lite twice on checkout, and conflict warnings about .cvsignore,
> even though I haven't modified anything. Perhaps it's due to an empty
> "D" line I get at the end of expat-lite/CVS/Entries, which is really
> weird. I'm using CVS 1.10.3; should I upgrade that?
Yes, upgrade and try again; if you still have the problem, please let
us know.
Thanks,
-Karl
Re: Yet another newbie
Posted by Karl Fogel <kf...@galois.collab.net>.
Branko =?iso-8859-2?Q?=C8ibej?= <br...@hermes.si> writes:
> In fact, everything is fine until I check out the apr/ directory
> into the source tree. Looks like my CVS doesn't like to have the
> working copy pulled from different servers; or rather, it bonks
> the existing working copy.
Yep, upgrade the client.
Re: Yet another newbie
Posted by Branko Čibej <br...@hermes.si>.
I wrote:
> 3) Oh, yes: something seems to be wrong with the CVS repository. I get
> expat_lite twice on checkout, and conflict warnings about .cvsignore,
> even though I haven't modified anything. Perhaps it's due to an empty
> "D" line I get at the end of expat-lite/CVS/Entries, which is really
> weird. I'm using CVS 1.10.3; should I upgrade that?
In fact, everything is fine until I check out the apr/ directory
into the source tree. Looks like my CVS doesn't like to have the
working copy pulled from different servers; or rather, it bonks
the existing working copy.
Brane
--
Branko Čibej <br...@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49 fax: (+386 1) 586 52 70