Groups > comp.lang.c > #61737 > unrolled thread

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

Started by	G G <gdotone@gmail.com>
First post	2015-05-07 17:12 -0700
Last post	2015-05-08 05:12 +0000
Articles	17 on this page of 57 — 16 participants

Back to article view | Back to comp.lang.c

Page 3 of 3 — ← Prev page 1 2 [3]

#63107

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2015-06-09 16:48 +0100
Message-ID	<87sia0992a.fsf@bsb.me.uk>
In reply to	#63105

David Kleinecke <dkleinecke@gmail.com> writes:
<snip>
> I don't think the standard (any standard) is clear on this point.

I see a theme emerging.  Over in comp.theory it was the textbooks on
theoretical CS (and Turing's original paper) there were unclear about
what was permitted on a Turing machine's tape.

Meanwhile, back in the land of topicality, will you ever answer my
questions about my use of the ## operator?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#63108

From	Keith Thompson <kst-u@mib.org>
Date	2015-06-09 08:55 -0700
Message-ID	<87a8w8ri4z.fsf@kst-u.example.com>
In reply to	#63105

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?

-- 
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"

[toc] | [prev] | [next] | [standalone]

#63150

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-06-10 10:09 -0700
Message-ID	<cac6bc27-17ed-4b20-8a88-45f5a8df6560@googlegroups.com>
In reply to	#63108

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.

[toc] | [prev] | [next] | [standalone]

#63155

From	Keith Thompson <kst-u@mib.org>
Date	2015-06-10 11:05 -0700
Message-ID	<87k2vbigmd.fsf@kst-u.example.com>
In reply to	#63150

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"

[toc] | [prev] | [next] | [standalone]

#63191

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-06-11 11:04 -0700
Message-ID	<8a923aab-ebb9-4291-a8c7-8a564492e381@googlegroups.com>
In reply to	#63155

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". 

As to the broader question - yes, I think the standard is an expository
mess. But I see reason to rail against it because I have no hope of
changing it even a little. Too much of the mess is dictated by the way
(which I deplore) that standars are written.

In my ideal world there would be no standards - just a test suite. The
test suite is made up of "strictly conforming programs". If a compiler
compiles all of them to the expected result it is a conforming compiler.

The fly in this ointment is the need to see that the abstract C machine 
generated by a compiler give the expected reults. Essentially the 
operational programs resulting from compilation each need a test suite
of their own. 

Since I am talking an ideal word I have no fear of immense number of
test cases I am specifying. The whole  can be easily automated.

[toc] | [prev] | [next] | [standalone]

#63193

From	Keith Thompson <kst-u@mib.org>
Date	2015-06-11 11:31 -0700
Message-ID	<87y4jqgkq5.fsf@kst-u.example.com>
In reply to	#63191

David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, June 10, 2015 at 11:05:25 AM UTC-7, Keith Thompson wrote:
[...]
>> 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". 

Interesting.  That appears to have been an error in the C90 standard.
In the C99 and C11 standards, "operators" are not preprocessor-tokens.
Instead, the list is:

    header-name
    identifier
    pp-number
    character-constant
    string-literal
    punctuator
    each non-white-space character that cannot be one of the above

The preprocess treats "sizeof" as an identifier.  I believe that was the
intent in C90, expressed more clearly in C99 and C11.

> As to the broader question - yes, I think the standard is an expository
> mess.

That hardly answers my question, which was "What else do you think is
unclear?".

>       But I see reason to rail against it because I have no hope of
> changing it even a little. Too much of the mess is dictated by the way
> (which I deplore) that standars are written.
>
> In my ideal world there would be no standards - just a test suite. The
> test suite is made up of "strictly conforming programs". If a compiler
> compiles all of them to the expected result it is a conforming compiler.

I have difficulty imagining how you'd write such a test suite without a
document defining the rules of the language.

One data point: Ada has both an official standard document and a test
suite.

[...]

-- 
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"

[toc] | [prev] | [next] | [standalone]

#63199

From	Malcolm McLean <malcolm.mclean5@btinternet.com>
Date	2015-06-11 13:49 -0700
Message-ID	<2648ad4e-1d09-4b5a-8b05-8245b5a53fa7@googlegroups.com>
In reply to	#63191

On Thursday, June 11, 2015 at 7:05:11 PM UTC+1, David Kleinecke wrote:
> 
> In my ideal world there would be no standards - just a test suite. The
> test suite is made up of "strictly conforming programs". If a compiler
> compiles all of them to the expected result it is a conforming compiler.
> 
There's a program called ctorture which is designed to stress test 
compilers. However the ANSI committee refused to give it any sort
of official status. I don't know how widely used it is, but I suspect
most compiler authors run it through their creations.

I don't know the committee's reasons, but if you're using a test suite
both to develop a program, and to claim correctness after development
is completed, then that's a classic situation where errors are likely 
to slip through.

[toc] | [prev] | [next] | [standalone]

#63219

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-06-12 09:00 -0700
Message-ID	<4615b4cf-a600-43c8-b9bd-a1585ffd9bea@googlegroups.com>
In reply to	#63199

On Thursday, June 11, 2015 at 1:49:14 PM UTC-7, Malcolm McLean wrote:
> On Thursday, June 11, 2015 at 7:05:11 PM UTC+1, David Kleinecke wrote:
> > 
> > In my ideal world there would be no standards - just a test suite. The
> > test suite is made up of "strictly conforming programs". If a compiler
> > compiles all of them to the expected result it is a conforming compiler.
> > 
> There's a program called ctorture which is designed to stress test 
> compilers. However the ANSI committee refused to give it any sort
> of official status. I don't know how widely used it is, but I suspect
> most compiler authors run it through their creations.
> 
> I don't know the committee's reasons, but if you're using a test suite
> both to develop a program, and to claim correctness after development
> is completed, then that's a classic situation where errors are likely 
> to slip through.

There has been plenty of discussion of test suites and opinions seem to
differ. I would say that in the situation of your last paragraph any
error would demonstrate that your test suite was inadequate. It thus puts
the burden on the test suite. If some code passes the test suite it is,
technically speaking, not an error even if it doesn't do what you imagine
it should do. The few cases I've seen involved behavior that was not
foreseen (and therefore tested) but when encountered was not what "should
have happened".  That is, the compiler cannot read the programmer's mind.

[toc] | [prev] | [next] | [standalone]

#65270

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-07-11 07:25 -0700
Message-ID	<kfn380u22lu.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#63191

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.

[toc] | [prev] | [next] | [standalone]

#65314

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-07-11 10:04 -0700
Message-ID	<a3e0e708-1290-48e1-94fa-86a8e578c87a@googlegroups.com>
In reply to	#65270

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. So far as I can tell this ambiguity makes no effective
difference in anything. But it distracts from the elegance of the
standard.

[toc] | [prev] | [next] | [standalone]

#65316

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-07-11 13:39 -0400
Message-ID	<55A154DF.2040204@verizon.net>
In reply to	#65314

On 07/11/2015 01:04 PM, David Kleinecke wrote:
> On Saturday, July 11, 2015 at 7:25:35 AM UTC-7, Tim Rentsch wrote:
...
>> 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. So far as I can tell this ambiguity makes no effective
> difference in anything. But it distracts from the elegance of the
> standard.

You're probably referencing the C90 standard, because that description
doesn't match the current standard. You'll be pleased to know, I assume,
that in C99 and later versions there is no such ambiguity.

There are two separate grammars for C. The lexical grammar summarized in
Appendix A.1 applies to pre-processing tokens during translation phases
3-5. Preprocessing tokens are converted to tokens during translation
phase 6. The phrase structure grammar described in A.2 applies to tokens
during translation phase 7.
Most operators parse as punctuators (6.4.6p1), throughout phases 3-7,
while sizeof parses as an identifier (6.4.2.1p1) during phases 3-5, and
as a keyword (6.4.1p1) token during phase 7. All of the relevant
categories are well defined, there is no ambiguity.
Neither grammar identifies a syntactic category that includes all
operators - because there are no grammar rules where such a category
would be useful. The phrase structure grammar does define unary-operator
and assignment-operator, because those categories are used in grammar
productions (6.5.3p1 and 6.5.16p1, respectively). But most operators
appear in the grammar only on their own, in their own grammar
productions, with sizeof appearing in two of the grammar productions for
unary-expression.

[toc] | [prev] | [next] | [standalone]

#65336

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2015-07-11 13:44 -0700
Message-ID	<kfntwtav2zo.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#65314

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.

[toc] | [prev] | [next] | [standalone]

#65365

From	Keith Thompson <kst-u@mib.org>
Date	2015-07-11 16:15 -0700
Message-ID	<ln615qp9ps.fsf@kst-u.example.com>
In reply to	#65314

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> 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. So far as I can tell this ambiguity makes no effective
> difference in anything. But it distracts from the elegance of the
> standard. 

This ambiguity in the obsolete C90 standard was resolved in
later editions.  "Operators" are no longer one of the kinds of
preprocessing tokens.

-- 
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"

[toc] | [prev] | [next] | [standalone]

#63106

From	David Kleinecke <dkleinecke@gmail.com>
Date	2015-06-09 08:31 -0700
Message-ID	<33f6567f-3c86-4463-956e-f784d5bef739@googlegroups.com>
In reply to	#63095

On Monday, June 8, 2015 at 2:03:28 PM UTC-7, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
> (snip) 
> > Because this strictly conforming program:
>  
> > #include <stdio.h>
> > #include <stddef.h>
> > int main(void) {
> > #ifdef size_t
> >    puts("size_t is a macro");
> > #else
> >    puts("size_t is not a macro");
> > #endif
> >    {
> >        char *size_t = "Because, among other things, if size_t were "
> >                       "a macro, this would be a syntax error";
> >    }
> >    return 0;
> > }
>  
> > must print "size_t is not a macro".
> 
> Maybe I am missing something (likely), but why can't size_t be
> a macro that expands to a typedef name?  That is, with the appropriate
> macro expansion it wouldn't be a syntax error, but still would print
> "size_t is a macro".
 
That, of course, is what I meant when I asked the question. I didn't
think that I needed to explain what seemed obvious.

    #define size_t int

If I do this the token "size_t" never survives the preprocessor. But
some "legal" statements like
    
    size_t size_t;

become "illegal" statements (because int is a keyword)

    int int;

[toc] | [prev] | [next] | [standalone]

#61748

From	Malcolm McLean <malcolm.mclean5@btinternet.com>
Date	2015-05-07 20:34 -0700
Message-ID	<81e66df4-ddcd-4c92-b53c-e4d55d93b5d8@googlegroups.com>
In reply to	#61737

On Friday, May 8, 2015 at 1:12:47 AM UTC+1, G G wrote:
> Could you please discuss whether casting a size_t variable
> to an unsigned variable the correct way to handle a warning
> I'm getting when I compile the program that follows.
> 
> Inside the function mode(), rating is declared as a size_t variable.
>
size_t is a nuisance. 
The obvious variable type to use for an array index is int. It's
very rare for arrays to go over the range of an int, int is 
supposed to be the "natural" integer size, and can be presumed to
be fast, and, most importantly, it's signed, which means that
calculations of (i -1) go, correctly, to -1 rather than wrapping
round. That's often important.
However size_t has been allowed into the language, and library writers
tend to use it for any count. So you have a problem - either warnings,
or make everything a size_t, in which case int just fades away. And
no-one wants to use a language where an index variable is called a
size_t.

[toc] | [prev] | [next] | [standalone]

#61754

From	Richard Heathfield <rjh@cpax.org.uk>
Date	2015-05-08 09:48 +0100
Message-ID	<miht6p$p23$1@dont-email.me>
In reply to	#61748

On 08/05/15 04:34, Malcolm McLean wrote:
> On Friday, May 8, 2015 at 1:12:47 AM UTC+1, G G wrote:
>> Could you please discuss whether casting a size_t variable
>> to an unsigned variable the correct way to handle a warning
>> I'm getting when I compile the program that follows.
>>
>> Inside the function mode(), rating is declared as a size_t variable.
>>
> size_t is a nuisance.

In Malcolm's opinion, size_t is a nuisance. That is not the only opinion.

> The obvious variable type to use for an array index is int.

Why do you need a signed type? I don't get it.

> It's
> very rare for arrays to go over the range of an int, int is
> supposed to be the "natural" integer size, and can be presumed to
> be fast, and, most importantly, it's signed, which means that
> calculations of (i -1) go, correctly, to -1 rather than wrapping
> round. That's often important.

Why is it so important to move the bug? Wouldn't it be better to 
/re/move it?


> However size_t has been allowed into the language, and library writers
> tend to use it for any count. So you have a problem - either warnings,
> or make everything a size_t, in which case int just fades away. And
> no-one wants to use a language where an index variable is called a
> size_t.

And yet here we are.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#61750

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date	2015-05-08 05:12 +0000
Message-ID	<mihgkr$6a4$1@speranza.aioe.org>
In reply to	#61737

G G <gdotone@gmail.com> wrote:
> Could you please discuss whether casting a size_t variable
> to an unsigned variable the correct way to handle a warning
> I'm getting when I compile the program that follows.

> Inside the function mode(), rating is declared as a size_t variable.
> Ok, that makes sense to me because in the function, rating is
> is used as a subscript for an array. In order to capture the mode
> value, the author uses the variable rating and assigns it to
> modeValue which is declared as an unsigned int.

(snip)

> In order to remove the warning I cast rating to ( unsigned int ).
> I guess in a simple program such as this it does not matter, but
> can should I do this anytime I run across a situation like this.

Theoretically, int could be a 16 bit type. 

That isn't likely on the usual 32 bit system most of us use,
but could still be on smaller, embedded systems.

If you are sure enough that (unsigned int) is 32 bits, and 
that 32 bits is enough for your problem, then go ahead.

If there is a possibility that unsigned int is 16 bits, and
that won't be enough, you should go through and use size_t
as appropriate.

-- glen

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

csiph-web

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

Contents

#63107

#63108

#63150

#63155

#63191

#63193

#63199

#63219

#65270

#65314

#65316

#65336

#65365

#63106

#61748

#61754

#61750