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 <[email protected]>: >> >>> 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/ _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
