Re: Could you please discuss whether casting a size_t variable to unsigned int variable is the correct way to handle...

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 <kst-u@mib.org>
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> (permalink)
References	<a148e69a-0699-419d-ac3e-2fff86c8a158@googlegroups.com> <87ioc3j29h.fsf@kst-u.example.com> <3cd2ac79-aeaa-4b7a-91d7-6fc63f592f72@googlegroups.com> <87a8xfi01c.fsf@kst-u.example.com> <kfnvbg0e76h.fsf@x-alumni2.alumni.caltech.edu> <876180gufr.fsf@kst-u.example.com> <5922caf7-6301-40f8-8f28-64c1346774e2@googlegroups.com> <87mw0aqce9.fsf@kst-u.example.com> <ml4vul$gmm$1@speranza.aioe.org> <87egllrhoy.fsf@kst-u.example.com> <56301485-e5e9-45c7-8357-9a9b21327747@googlegroups.com> <87a8w8ri4z.fsf@kst-u.example.com> <cac6bc27-17ed-4b20-8a88-45f5a8df6560@googlegroups.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

Show key headers only | View raw

David Kleinecke <dkleinecke@gmail.com> writes:
> On Tuesday, June 9, 2015 at 8:55:33 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> 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 <math.h> 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  <http://www.ghoti.net/~kst>
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"

Thread

csiph-web