Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!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: Sun, 24 May 2015 13:36:18 -0700 Organization: None to speak of Lines: 48 Message-ID: <87egm5pvb1.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> <87oalg2zq0.fsf@kst-u.example.com> <792ce9c8-075c-4b19-8a2f-ac75dab1a178@googlegroups.com> <87y4kj1667.fsf@kst-u.example.com> <87h9r5u97m.fsf@kst-u.example.com> <5218fb08-39ea-4b78-9e14-5d946aade48c@googlegroups.com> <878ucgsau6.fsf@kst-u.example.com> <7b99e2eb-6b33-4ad4-b4a6-647a44d1e181@googlegroups.com> <87617jq7uk.fsf@kst-u.example.com> <38aa2597-41d3-4b49-8093-f443b0fbdbc6@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="9be37d943435275679235b07c7947eef"; logging-data="27258"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18N/BM8jMcauaWDuPw+BQ+I" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:ExW8NTIafFnkGZpxqyQDpIXkKA4= sha1:qVcSG5CBzldcbCab1DbE2EroENY= Xref: csiph.com comp.lang.c:62544 David Kleinecke writes: > On Saturday, May 23, 2015 at 2:53:19 PM UTC-7, Keith Thompson wrote: >> And a C90 compiler is permitted to predefine such a >> macro even without an explicit #define in any header. Any program >> that declares or defines such an identifier *even without including >> any standard header* has undefined behavior. The standard explicitly >> says so. (It's 7.1.3 paragraphs 1 and 2 in C11; my copy of the >> C90 standard is difficult to search, but I'm sure you can find >> it yourself.) > > In my copy of the C90 standard 7.1.3 is the section about reserved > identifiers. I cannot find the words "even without including any > standard header has undefined behavior." Of course not. That was my conclusion from what that section says. I never claimed those exact words were there. If I had been quoting from the standard, I would have used quotation marks. > As I read what you wrote you believe that a compiler can define a > macro prior to any tanslation unit - something I believe does not > happen - but the standard says the behavior is undefined and that, > because the behavior is undefined it can be anything the > implementation makes of it. Yes. To be clear, the behavior of a program that declares or defines a reserved identifier is undefined. > If I understand you correctly I believe you are at least admitting > the existence of some very bad practice. I would consider any use > of undefined behavior a coding error - it is not transferable. The use of a reserved identifier in the code in question causes that code to have undefined behavior (behavior that is not defined by the C standard). It's not a choice I would have made; on the other hand, a lot of useful code has undefined behavior. Probably the authors decided the advantages of using that identifier (and avoiding collisions with user code) outweighed the risks. I don't know what you think I'm "admitting", nor do I understand what you mean by "it is not transferable". [...] -- 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"