From: Florian Weimer <fw@deneb.enyo.de>
To: git@vger.kernel.org
Subject: Re: [PATCH v2] Make fetch-pack a builtin with an internal API
Date: Mon, 09 Jul 2007 17:10:36 +0200 [thread overview]
Message-ID: <874pkdlij7.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20070709144030.GE16032@thunk.org> (Theodore Tso's message of "Mon, 9 Jul 2007 10:40:30 -0400")
* Theodore Tso:
> On Mon, Jul 09, 2007 at 02:16:35PM +0100, Andy Parkins wrote:
>> 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.
No, they are are reserved.
> 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.
This is not sufficient because the implementation might have a
*typedef* for _my_strdup in any header file, and neither translation
unit would compile. Or they could have been declared with a different
prototype.
next prev parent reply other threads:[~2007-07-09 15:10 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
2007-07-09 15:10 ` Florian Weimer [this message]
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=874pkdlij7.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=git@vger.kernel.org \
/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.