All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.