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

From	Tim Rentsch <txr@alumni.caltech.edu>
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	2015-07-11 13:44 -0700
Organization	A noiseless patient Spider
Message-ID	<kfntwtav2zo.fsf@x-alumni2.alumni.caltech.edu> (permalink)
References	(12 earlier) <cac6bc27-17ed-4b20-8a88-45f5a8df6560@googlegroups.com> <87k2vbigmd.fsf@kst-u.example.com> <8a923aab-ebb9-4291-a8c7-8a564492e381@googlegroups.com> <kfn380u22lu.fsf@x-alumni2.alumni.caltech.edu> <a3e0e708-1290-48e1-94fa-86a8e578c87a@googlegroups.com>

Show all headers | View raw

David Kleinecke <dkleinecke@gmail.com> writes:

> On Saturday, July 11, 2015 at 7:25:35 AM UTC-7, Tim Rentsch wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>
>>> On Wednesday, June 10, 2015 at 11:05:25 AM UTC-7, Keith Thompson wrote:
>>>> 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.)
>>>
>>> There are (in the C90 standards) at 6.1 eight different kinds of
>>> preprocessor tokens listed.  The sixth of these is "operator".  The
>>> operators are listed at 6.1.5 and include "sizeof".  Perhaps you could
>>> argue that this does't mean the preprocessor "recognizes" sizeof.  It
>>> does insure that the preprocessor does not treat it as a token like
>>> the other keywords.
>>>
>>> I was well aware that keywoeds in general were not protected - which is
>>> why I excepted "sizeof". 
>>
>> In C90 'sizeof' is a keyword, and an operator, and an identifier.
>> Since it is an identifier, how it is treated by the preprocessor
>> is described in 6.8.1 p1.
>
> The pre-processor doesn't know about keywords.  6.1 lists what the
> preprocessing tokens are.  Two of the categories are identifier and
> operator.  "sizeof" is, of course, a identifier but it is also listed
> (6.1.5) as an operator.  This is an ambiguity which I think people
> would resolve in favor of 6.1.5 because "sizeof" actually is an
> operator.  [snip]

I'm sorry you find the matter so disconcerting.  I don't know
anyone else that is bothered by it.

Thread

csiph-web