From: Theodore Tso <tytso@mit.edu>
To: Andy Parkins <andyparkins@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Daniel Barkalow <barkalow@iabervon.org>
Subject: Re: [PATCH v2] Make fetch-pack a builtin with an internal API
Date: Mon, 9 Jul 2007 10:40:30 -0400 [thread overview]
Message-ID: <20070709144030.GE16032@thunk.org> (raw)
In-Reply-To: <200707091416.39949.andyparkins@gmail.com>
On Mon, Jul 09, 2007 at 02:16:35PM +0100, Andy Parkins wrote:
> On Monday 2007 July 09, Theodore Tso wrote:
> > On Sun, Jul 08, 2007 at 10:39:41PM -0700, Junio C Hamano wrote:
> > > Are _identifiers with leading underscore Kosher thing to do, I
> > > wonder... We do have ones with trailing ones (mostly qsort
> > > functions) and I think they are done that way for the sake of
> > > standards conformance.
> >
> > _[a-z]* is kosher for file scopes or function scoping:
>
> Perhaps I'm reading it wrong but:
>
> "All identifiers beginning with an underscore are reserved for ordinary
> identifiers (functions, variables, typedefs, enumeration constants) with file
^^^^^^^^^
> scope."
^^^^^^
>
> Doesn't agree with what you've said. I think that you _can_ use _[a-z]* for
> labels or structure members - however, not within file or function scope.
I think the above does agree with what I said. It says that you can
use functions, variables, typdefs, enumeration constants (not just
labels or structure members) WITH FILE SCOPE. I.e., so long as it
doesn't leak across a .o linkage. So one .o file can use a static
_my_strdup, and another .o file can use a static _my_strdup, and they
don't have to worry about multiply defined function conflicts, since
they are static functions with file or smaller scoping.
And if it's safe to use a file-level static scoping, then obviously it
would be safe to use a function-level static scoping.
> However, the rule of thumb I've always used is "don't start identifiers with
> underscore". I can't think of a situation that would mean you have to use an
> underscore to start an identifier - so why get into detailed worries about
> where it's allowed and where it isn't. Just don't use it. The document you
> linked to gives exactly this advice:
Yep, this is the safer thing to do if you don't want to remember the
more complicated rule. But it's not *necessary*; no system library
will use a single underscore followed by a lower-case letter, since
that's reserved for programs for local file-level scoping. A system
library will use for its private function identifiers that begin
either a double underscore, or a underscore followed by an uppercase
latter.
Regards,
- Ted
next prev parent reply other threads:[~2007-07-09 14:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-09 5:10 [PATCH v2] Make fetch-pack a builtin with an internal API Daniel Barkalow
2007-07-09 5:39 ` Junio C Hamano
2007-07-09 6:37 ` Daniel Barkalow
2007-07-09 18:04 ` René Scharfe
2007-07-09 18:16 ` Daniel Barkalow
2007-07-09 11:50 ` Theodore Tso
2007-07-09 13:16 ` Andy Parkins
2007-07-09 14:40 ` Theodore Tso [this message]
2007-07-09 15:10 ` Florian Weimer
2007-07-09 15:28 ` Andy Parkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070709144030.GE16032@thunk.org \
--to=tytso@mit.edu \
--cc=andyparkins@gmail.com \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.