Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: A Note on Readability Date: Tue, 19 May 2015 11:23:35 -0700 Organization: None to speak of Lines: 74 Message-ID: <87oalg2zq0.fsf@kst-u.example.com> References: <1d72d1ba-3317-4725-bedd-698843ca9c35@googlegroups.com> <0f9297b6-2d4c-4d12-8e97-470027248f72@googlegroups.com> <85343d47-257a-4403-9672-40991134ba13@googlegroups.com> <55587201.6548218@news.xs4all.nl> <67b5daac-4378-458c-a6d0-fbf4e20d8340@googlegroups.com> <29103fb2-ce27-4c7f-a189-8ff170f5e246@googlegroups.com> <555A2A66.1040201@verizon.net> <70adeda1-3b83-4a96-b57b-59ac062f0bc6@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="9be37d943435275679235b07c7947eef"; logging-data="26224"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19qKvuHBfUO8f1AQrdUsB+0" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:OVHEdiYFttkhLbmFi8z473ACjXE= sha1:WGJvflsGqEHGqXsZ1ylsYzgfY5E= Xref: csiph.com comp.lang.c:62314 David Kleinecke writes: > On Monday, May 18, 2015 at 11:07:42 AM UTC-7, James Kuyper wrote: >> On 05/18/2015 01:38 PM, David Kleinecke wrote: >> > On Sunday, May 17, 2015 at 10:06:31 AM UTC-7, Richard Heathfield wrote: >> ... >> >> You are mistaken. The naming rules /are/ part of the C language. See for >> >> example 4.1.2 of C89 or Section 7.1.3 of C99 onwards. >> ... >> > In my copy of the C90 standard there is no 4.1.2. and Part 4 - entitled >> > Compliance - does not discuss naming rules. >> >> C90 differs from C89 almost entirely by the addition of 3 sections at >> the beginning required by ISO document conventions, with the result that >> all other section numbers increased by 3. Thus, section 4.1.2 of C89 >> would correspond to 7.1.2 of C90. I don't have a copy of either >> standard, so I cannot confirm that either section number is correct, but >> it is section 7.1.3 in later versions of the standard, which I do have >> copies of, so that puts it in the right general region of the document. > > In the C90 standard Part 7 is the Library. 7.1.2 describes Standard > headers and 7.1.3 is about Reserved Headers does is in fact what you > wanted. > > Since I was copying GTK+ code and not advancing my own I don't feel very > apologetic. Personally I never start a name with an underscore. Since > GTK+ compiles (I assume) either gcc (assumed) does not enforce the rules > about reserved headers or has a way to turn the enforcement off. There are no rules to enforce. The standard says that code outside the implementation that uses identifiers that are reserved to the implementation has undefined behavior. There is no requirement for compilers to detect or diagnose improper use of reserved identifiers. If I write (assume this is part of a complete program): int n = 42; printf("%d\n", n); it must print "42", or at least try to do so (assuming a conforming hosted implementation). If I write: int _N = 42; printf("%d\n", _N); the behavior is undefined. One very likely result is that it will print "42". Another possible result is that it will fail to compile because or the compiler uses _N for its own purposes. > I assume it is the standards committee that wants to keep the reserved > headers to themselves. You make it sound like the committee is hoarding identifiers for some nefarious purpose. I wouldn't put it that way. The standards committee wants to keep a particular set of identifiers reserved for implementers, guaranteeing that other identifiers are available for use in user code. This is primarily for the benefit of C programmers, who can depend on being able to use non-reserved identifiers without fear of collisions (though collisions with library code are still possible). I asked you a few days ago: [...] Do you think that identifiers starting with underscores *shouldn't* be reserved to the implementation? If so, how are implementations of the standard library supposed to be written without the risk of breaking user code? I don't recall that you ever replied. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"