Re: Adopt a platform today!

[David Chisnall]

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).

> 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.

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).  

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).

David


-- Send from my Jacquard Loom