Re: [PATCH v2] Make fetch-pack a builtin with an internal API
- From
- Andy Parkins <andyparkins@gmail.com>
- Date
- Jul 9, 2007, 13:16 UTC
- Message-ID
- <200707091416.39949.andyparkins@gmail.com>
- In-Reply-To
- <20070709115029.GD16032@thunk.org>
On Monday 2007 July 09, Theodore Tso wrote:
Show 7 quoted lines
> 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.
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:
"Don't give anything a name with a leading underscore."
> P.S. Note that the Linux kernel does not worry about such rules; in > particular, _[a-z]* is very commonly used at the global scope level, > without any problems. It doesn't have to be as portable as git > probably needs to be, however.
The kernel doesn't use any standard library so there is nothing for it to conflict with. I don't think it's that the kernel doesn't worry about those rules, it's that those rules don't apply (just as they don't for glibc). The underscore rules aren't a limitation of the language, they are a limitation imposed by the standard library.
Andy
-- Dr Andy Parkins, M Eng (hons), MIET andyparkins@gmail.com