Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.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:37:57 -0700 Organization: None to speak of Lines: 35 Message-ID: <87a8wtpv8a.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> <78c97d0b-fd34-41ed-aa2b-fe31a4ab393c@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="U2FsdGVkX1/dUyn9Dvq+wsvriGUZk8zC" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:EGzd6PxxYhXm3bNGP4USk+AjXCY= sha1:GumyKSa0boF8q1sQbRkInDpbXd4= Xref: csiph.com comp.lang.c:62545 David Kleinecke writes: > On Saturday, May 23, 2015 at 2:53:19 PM UTC-7, Keith Thompson wrote: >> David Kleinecke writes: >> >> > A program could make a structure tag a macro reference but it is hard >> > see a reason to do so. In any case were _GeditTab a macro reference the >> > preprocessor would change it and it would never interfer with a library >> > reference. >> >> If an implementation defines _GeditTab as, for example, void (for >> whatever reason), then the declaration >> struct _GeditTab { ... }; >> will fail to compile. It's unlikely to happen in practice, but it's >> perfectly legal for an implementation to do so. By defining _GeditTab, >> even as a struct tag, that library risks conflicting with some >> conforming C implementation. It's probably a small risk, and apparently >> one that the implementers of the library have chosen to accept, but it's >> non-zero -- and could have been avoided by choosing a non-reserved >> identifier. > > I thought of that but discounted it. The code would not compile because > "void" is a keyword and not an identifier. The library is never involved. Huh? The declaration `struct _GeditTab` is part of the library. That code has undefined behavior because of its use of a reserved identifier. The code failing to compile because "void" is a keyword is one possible consequence of the undefined behavior. -- 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"