Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.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: Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle... Date: Wed, 10 Jun 2015 11:05:14 -0700 Organization: None to speak of Lines: 97 Message-ID: <87k2vbigmd.fsf@kst-u.example.com> References: <87ioc3j29h.fsf@kst-u.example.com> <3cd2ac79-aeaa-4b7a-91d7-6fc63f592f72@googlegroups.com> <87a8xfi01c.fsf@kst-u.example.com> <876180gufr.fsf@kst-u.example.com> <5922caf7-6301-40f8-8f28-64c1346774e2@googlegroups.com> <87mw0aqce9.fsf@kst-u.example.com> <87egllrhoy.fsf@kst-u.example.com> <56301485-e5e9-45c7-8357-9a9b21327747@googlegroups.com> <87a8w8ri4z.fsf@kst-u.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="9be37d943435275679235b07c7947eef"; logging-data="27784"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19YYdvyc7lQT7RQ4WppxQLY" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:/2fq5OddR4V6pA1wxQixVDtpGRo= sha1:VJNFnno9WwEZ4ju6DyY/aRu/Uok= Xref: csiph.com comp.lang.c:63155 David Kleinecke writes: > On Tuesday, June 9, 2015 at 8:55:33 AM UTC-7, Keith Thompson wrote: >> David Kleinecke writes: >> > On Monday, June 8, 2015 at 2:52:55 PM UTC-7, Keith Thompson wrote: >> [...] >> >> 7.1.2p5 says: >> >> >> >> Any definition of an object-like macro described in this clause >> >> shall expand to code that is fully protected by parentheses >> >> where necessary, so that it groups in an arbitrary expression >> >> as if it were a single identifier. >> >> >> >> This cannot apply to a macro that expands to a typedef name. >> >> >> >> 7.1.4p1 gives explicit permission to define functions as macros. No >> >> such permission is given for type names. >> >> >> >> In general, I'd like to say that implementations aren't permitted to >> >> define identifiers in ways not explicitly permitted by the standard, >> >> but I'm not sure I can justify it rigorously. >> > >> > The preprocessor should not be aware of niceties like functions. It >> > should preprocess any code or chaos according to its rules. But, of >> > course, how do I know I can say "should"? >> >> The preprocessor isn't aware of functions. Did you think I was implying >> that it is? >> >> For example, an implementation of may include a macro >> definition like: >> #define sqrt(x) __builtin_sqrt(x) >> This causes the token sequence >> sqrt ( x ) >> to be replaced by the token sequence >> __builtin_sqrt ( x ) >> >> The preprocessor's behavior does not depend on the fact that sqrt and >> __builtin_sqrt are function names. >> >> > I think the preprocessor should operate on its own rules without >> > reference to the program structure. That is my opinion. >> >> It does. >> >> > I don't think the standard (any standard) is clear on this point. >> >> I believe it's quite clear. What do you think is unclear? > > #define size_t int > > The C90 preprocessor does not recogize keywords other than sizeof. So > we could replace > > #define int char > #define while if > > and things like that. My feeling is they don't really want that - but > I see no rule against it. The C90 (or C99, or C11) preprocessor does not recognize sizeof. An amusing historical aside: In 1998, someone posted this to comp.std.c: You are right. It was nice back in the days when things like #if (sizeof(int) == 8) actually worked (on some compilers). The response: Must have been before my time. Dennis Yes, that was Dennis Ritchie. Back to the issue at hand, there is no rule against redefining keywords as macros, other than N1570 7.1.2p4, which says: The program shall not have any macros with names lexically identical to keywords currently defined prior to the inclusion of the header or when any macro defined in the header is expanded. This is a "shall" outside any constraint, so violating it causes the program to have undefined behavior. What else do you think is unclear? (A suggestion: Rather than asserting that the standard is unclear or inconsistent, you might consider asking for clarification.) -- 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"