From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Theodore Tso <tytso@mit.edu>, 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 14:16:35 +0100 [thread overview]
Message-ID: <200707091416.39949.andyparkins@gmail.com> (raw)
In-Reply-To: <20070709115029.GD16032@thunk.org>
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.
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
next prev parent reply other threads:[~2007-07-09 13:16 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 [this message]
2007-07-09 14:40 ` Theodore Tso
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=200707091416.39949.andyparkins@gmail.com \
--to=andyparkins@gmail.com \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tytso@mit.edu \
/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.