Re: Adopt a platform today!

[Richard Frith-Macdonald]

On 22 Feb 2011, at 11:16, David Chisnall wrote:

> On 22 Feb 2011, at 09:11, SPUeNTRUP - Kai Henningsen wrote:
> 
>> Hallo David,
>> 
>> Am Tue, 22 Feb 2011 01:44:08 +0000
>> schrieb David Chisnall <csdavec@swan.ac.uk>:
>> 
>>> One thing I noticed is that a lot of the new ICU code is using variable 
>>> names that start with underscores.  The C standard specifically reserves 
>>> identifiers that start with an underscore for the implementation, and any C 
>>> compiler is completely at liberty to reject them or interpret them as 
>>> something completely random without deviating from the spec, so we really 
>>> should be using them in GNUstep, and especially not for things that are not 
>>> exported as symbols.
>>> 
>>> This includes instance variables, by the way - we use them in quite a few 
>>> places, which is very bad and something that we should avoid.  If something 
>>> needs to avoid conflicts with other code, use gs_ as the prefix, not _.
>> 
>> This happens not to be true.
>> 
>> Or more precisely, it is at best a half truth.
> 
> The relevant part of the spec:
> 
>> All identifiers that begin with an underscore and either an uppercase letter 
>> or another underscore are always reserved for any use.
> 
> This means that __ or _{uppercase} identifiers may be built in functions, 
> macros, non-standard qualifiers, standard qualifiers in the next version of 
> the spec, and so on.  Using them anywhere is pretty much guaranteed to break 
> somewhere, eventually (see glibc's use of __block as an argument name in 
> headers).

Yes ... I don't think anyone disagrees with that.

>> All identifiers that begin with an underscore are always reserved for use as 
>> identifiers with file scope in both the ordinary and tag name spaces.
> 
> This means that they may be built-in functions, globals, and so on.  These 
> may be referenced by some predefined macros or macros in system headers, 
> which means that you'll end up with some horribly confusing bugs that take 
> ages to find if you.

I don't understand your sentence above.

As far as I can see Kai's email was correct and a clear summary.

> Code in, for example, NSTimeZone, is using identifiers in the former class 
> for symbols in the file scope.  This is definitely and unambiguously wrong.  
> Using them in ivars is technically permitted, but may cause very confusing 
> problems if libc decides to use them as functions called by libc macros that 
> you use in a method (less common, but still possible).  

Yes I see one use of a bad name for a static function ... no idea why ... I'll 
change that.

> Since GNUstep is pedantic about the GNU coding conventions, I'd also refer 
> you to those, which reserve ALL identifiers in the second category for use by 
> glibc (which doesn't stop glibc inappropriately using identifiers in the 
> first category and breaking things).

I don't see that in the coding standards at http://www.gnu.org/prep/standards/