Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Null pointer constant

Started bybartc <bc@freeuk.com>
First post2017-06-18 17:15 +0100
Last post2017-06-19 12:34 -0700
Articles 11 on this page of 111 — 14 participants

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

Contents

  Null pointer constant bartc <bc@freeuk.com> - 2017-06-18 17:15 +0100
    Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-18 11:20 -0700
    Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-18 19:23 +0100
      Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-18 20:57 +0100
        Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-18 13:38 -0700
          Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 04:35 -0700
            Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-19 18:08 +0000
              Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 21:05 -0700
            Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:12 -0700
              Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 21:08 -0700
        Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 00:34 +0100
          Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 04:45 -0700
            Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 13:55 +0200
          Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 13:16 +0100
            Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 16:58 +0100
    Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-18 20:58 +0000
      Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 00:11 +0100
        Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 03:21 +0200
          Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 10:11 +0100
            Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 12:38 +0200
              Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 13:05 +0100
                Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 14:39 +0200
                  Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-19 11:06 -0400
                    Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 15:51 +0000
                      Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-19 12:22 -0400
                        Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 17:29 +0000
                          Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-19 13:45 -0400
                            Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:31 -0700
                  Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 15:10 +0000
                  Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 16:53 +0100
                    Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-19 13:06 -0400
                      Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 20:03 +0100
                    Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 22:37 +0200
                      Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 22:10 +0100
                        Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 14:25 -0700
                          Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 22:46 -0700
                            Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 08:43 -0700
                              Re: Null pointer constant supercat@casperkitty.com - 2017-06-20 09:17 -0700
                              Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-21 00:56 -0700
                                Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-21 10:07 -0700
                                  Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-21 23:52 -0700
                                    Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-22 10:12 -0700
                                      Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-22 17:33 -0700
                                        Re: Null pointer constant supercat@casperkitty.com - 2017-06-23 08:54 -0700
                    Re: Null pointer constant Manfred <invalid@invalid.add> - 2017-06-20 00:00 +0200
                      Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 15:27 -0700
                        Re: Null pointer constant supercat@casperkitty.com - 2017-06-19 16:38 -0700
                        Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-20 01:14 +0100
                          Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-20 12:03 +0100
                        Re: Null pointer constant Manfred <noname@invalid.add> - 2017-06-20 13:16 +0200
                          Re: Null pointer constant jameskuyper@verizon.net - 2017-06-20 05:34 -0700
                          Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 08:49 -0700
                        Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-20 16:35 +0000
                          Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-20 13:07 -0400
                            Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 17:29 +0000
                              Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-20 13:55 -0400
                                Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 18:06 +0000
                                  Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-20 14:42 -0400
                                    Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 19:10 +0000
                            Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-20 18:31 +0000
                              Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 18:36 +0000
                              Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-20 14:45 -0400
                          Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 17:14 +0000
                          Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 11:55 -0700
                            Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 19:23 +0000
                              Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-20 15:39 -0400
                                Re: Null pointer constant scott@slp53.sl.home (Scott Lurndal) - 2017-06-21 13:44 +0000
                                  Re: Null pointer constant scott@slp53.sl.home (Scott Lurndal) - 2017-06-21 13:49 +0000
                                Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-21 23:57 -0700
                                  Re: Null pointer constant Philip Lantz <prl@canterey.us> - 2017-06-28 20:04 -0700
                                  Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-07-10 08:38 -0700
                              Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 12:39 -0700
                                Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-20 20:53 +0100
                                  Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 13:07 -0700
                                Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 20:50 +0000
                                  Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 15:35 -0700
                          Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-21 00:26 -0700
                            Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-21 09:54 -0700
                              Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-21 13:09 -0400
                                Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-22 00:53 -0700
                              Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-21 18:09 +0100
                              Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-22 00:50 -0700
                  Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 10:24 -0700
                    Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 22:32 -0700
                  Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 19:40 +0100
                  Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:08 -0700
                    Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 20:32 +0100
                      Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:48 -0700
                      Re: Null pointer constant jameskuyper@verizon.net - 2017-06-19 13:08 -0700
                        Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-19 20:40 +0000
                        Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 22:01 +0100
                          Re: Null pointer constant supercat@casperkitty.com - 2017-06-19 14:15 -0700
                          Re: Null pointer constant jameskuyper@verizon.net - 2017-06-19 14:25 -0700
                    Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 21:06 +0000
                      Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 14:28 -0700
                        Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 21:35 +0000
                          Re: Null pointer constant supercat@casperkitty.com - 2017-06-19 14:48 -0700
                            Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-20 15:38 +0000
                          Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 15:16 -0700
                    Re: Null pointer constant supercat@casperkitty.com - 2017-06-19 14:29 -0700
                      Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 15:18 -0700
                        Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 22:48 -0700
                  Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-20 15:09 +0100
                Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 10:19 -0700
              Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 10:15 -0700
                Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 22:44 +0200
              Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:24 -0700
        Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 08:21 +0000
          Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 10:17 +0100
            Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 10:04 -0700
    Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:34 -0700

Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]

#112645

FromKeith Thompson <kst-u@mib.org>
Date2017-06-19 15:18 -0700
Message-ID<lnh8zbei59.fsf@kst-u.example.com>
In reply to#112640
supercat@casperkitty.com writes:
> On Monday, June 19, 2017 at 2:08:40 PM UTC-5, Keith Thompson wrote:
>> David Brown writes:
>> > On 19/06/17 14:05, bartc wrote:
>> [...]
>> >> (a,b,0) can't be an integer constant expression, even if a and b are
>> >> constants, because the language considers that nonsensical.
>> 
>> (a,b,0) isn't an integer constant expression because the language says
>> it isn't.  The standard expresses no opinion on how sensible it would
>> be.  (I wouldn't have any particular problem if the language permitted
>> comma operators in constant expressions, but forbidding them isn't a
>> problem either.)
>
> The Standard N1570 6.6p10 says "An implementation may accept other forms
> of constant expressions."

True.  (I doubt that a compiler would accept comma expressions as
constant expressions, but one could.)

> While the rest of the Standard may specify that an implementation would be
> under no *obligation* to accept "(a,b,0)" as an integer constant expression,
> 6.6p10 would suggest to me that such an expression would be an integer
> constant expression on any implementation that, for whatever reason, chooses
> to regard it as such.
>
> N1570 6.3.2.3p3 says that an integer constant expression with value zero is
> a null-pointer constant.  I see no reason that, combined with the latitude
> given in 6.6p10, would not imply that an implementation may silently allow
> any integer expression *whose value is always zero* to be coerced to a
> pointer type, without regard for whether the Standard would *require* it to
> recognize that value as constant.

Thank you for explaining to us what "An implementation may accept other
forms of constant expressions" means, but I think we would have figured
it out.

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

#112666

FromTim Rentsch <txr@alumni.caltech.edu>
Date2017-06-19 22:48 -0700
Message-ID<kfnshiv6wg0.fsf@x-alumni2.alumni.caltech.edu>
In reply to#112645
Keith Thompson <kst-u@mib.org> writes:

> supercat@casperkitty.com writes:
>
>> On Monday, June 19, 2017 at 2:08:40 PM UTC-5, Keith Thompson wrote:
>>
>>> David Brown writes:
>>>
>>>> On 19/06/17 14:05, bartc wrote:
>>>
>>> [...]
>>>
>>>>> (a,b,0) can't be an integer constant expression, even if a and b are
>>>>> constants, because the language considers that nonsensical.
>>>
>>> (a,b,0) isn't an integer constant expression because the language says
>>> it isn't.  The standard expresses no opinion on how sensible it would
>>> be.  (I wouldn't have any particular problem if the language permitted
>>> comma operators in constant expressions, but forbidding them isn't a
>>> problem either.)
>>
>> The Standard N1570 6.6p10 says "An implementation may accept other forms
>> of constant expressions."
>
> True.  (I doubt that a compiler would accept comma expressions as
> constant expressions, but one could.)
>
>> While the rest of the Standard may specify that an implementation would be
>> under no *obligation* to accept "(a,b,0)" as an integer constant expression,
>> 6.6p10 would suggest to me that such an expression would be an integer
>> constant expression on any implementation that, for whatever reason, chooses
>> to regard it as such.
>>
>> N1570 6.3.2.3p3 says that an integer constant expression with value zero is
>> a null-pointer constant.  I see no reason that, combined with the latitude
>> given in 6.6p10, would not imply that an implementation may silently allow
>> any integer expression *whose value is always zero* to be coerced to a
>> pointer type, without regard for whether the Standard would *require* it to
>> recognize that value as constant.
>
> Thank you for explaining to us what "An implementation may accept other
> forms of constant expressions" means, but I think we would have figured
> it out.

Note that his conclusion is wrong.  An expression like '(a,b,0)'
could be accepted as a null pointer constant, but doing so
requires a diagnostic.

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

#112686

Frombartc <bc@freeuk.com>
Date2017-06-20 15:09 +0100
Message-ID<J0a2B.13867$0j3.7020@fx33.am4>
In reply to#112557
On 19/06/2017 13:39, David Brown wrote:
> On 19/06/17 14:05, bartc wrote:

>> If X is needed to implement a feature properly or to diagnose an error,
>> but only some compilers bother, then I won't either.
> 
> You are aiming to be the lowest of all compilers, with the least
> features and the most bugs?

Sometimes I will expend more effort than another compiler, when I think 
it is important. Take this declaration (where there are no types a, b or 
c in scope):

   int fn(a,b,c);

Most compilers will generate a warning.

Tiny C doesn't (which you will say is acceptable; I wouldn't. Tiny C is 
far from a toy compiler.).

But neither does MSVC, and this time it can't be anything to do with 
poor support for C99 or C11.

This kind of error has come up constantly, when a, b or c /is/ an actual 
typedef, but for various reasons, is not in scope (some mixup of headers 
or #ifdef or #define mean the typedef was not visible).

This is similar to the case where fn is not declared at all. But here, 
fn /is/ declared, yet the compiler will still now diagnose any incorrect 
or contradictory parameter types.

 > You are aiming to be the lowest of all compilers, with the least
 > features and the most bugs?

Being stricter and catching more errors than all those other compilers 
makes it bad?

-- 
bartc

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

#112599

FromKeith Thompson <kst-u@mib.org>
Date2017-06-19 10:19 -0700
Message-ID<lnzid3gak8.fsf@kst-u.example.com>
In reply to#112552
bartc <bc@freeuk.com> writes:
> On 19/06/2017 11:38, David Brown wrote:
>> On 19/06/17 11:11, bartc wrote:
>>> But it was hardly necessary to check that, as plenty of programs rely on
>>> using ?: in constant expressions, including that assert macro of a few
>>> weeks back which declared an array parameter bound as either 1 or 0.
>> 
>> Yes, and did you also look up "/integer/ constant expression" - the
>> particular type of constant expression Ike referred to?
>
> Are you referring to 6.6.6? According to that, 0+0 is not an integer 
> constant expression as "+" isn't one of the allowed operators that it lists.

You've misinterpreted 6.6p6.

6.6p3 specifies the operators that *cannot* appear in a constant
expression; all other operator are permitted.  6.6p6 imposes
restrictions on the operands in an integer constant expression.
`0+0` is an integer constant expression.

[...]

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

#112598

FromKeith Thompson <kst-u@mib.org>
Date2017-06-19 10:15 -0700
Message-ID<ln4lvbhpaf.fsf@kst-u.example.com>
In reply to#112540
David Brown <david.brown@hesbynett.no> writes:
> On 19/06/17 11:11, bartc wrote:
>> On 19/06/2017 02:21, David Brown wrote:
>>> On 19/06/17 01:11, bartc wrote:
>> 
>>>> (a?b:c) can be a constant expression, provided a, b and c are constants.

Correction: It can be a constant expression, provided a, b, and c are
constant expressions.  (I'm assuming a, b, and c are intended to
represent arbitrary subexpressions and needn't be just identifiers.)
Apart from that quibble, bartc's statement is correct.

>>> I presume you haven't bothered looking at the standard to see what a
>>> "constant expression" actually /is/, in the C standards?  And in
>>> particular, you haven't looked at what an "integer constant
>>> expression" is?
>> 
>> The standard says this:
>> 
>>   "constant-expression:  conditional-expression"
>> 
>> A condition-expression can be a a?b:c operation.
>> 
>> But it was hardly necessary to check that, as plenty of programs rely on
>> using ?: in constant expressions, including that assert macro of a few
>> weeks back which declared an array parameter bound as either 1 or 0.
>
> Yes, and did you also look up "/integer/ constant expression" - the
> particular type of constant expression Ike referred to?

David, your previous followup seemed to imply that a conditional
expression cannot be an integer constant expression.  In fact it can;
for example `1?0:0` is both an integer constant expression and a null
pointer constant.

But a conditional expression can be a constant expression only if all
three of its operands are constant expressions.

>>>> But, the restrictions on being able to use 0 as a null pointer
>>>> constant only in certain kinds of expressions sound like another quirk.
>>>
>>> This is clearly explained in the standards.
>> 
>> The standard says this:
>> 
>> 6.3.2.3p3:
>> 
>>  "An integer constant expression with the value 0, or such an
>>   expression cast to type void *, is called a null pointer constant."
>> 
>> So this term:
>> 
>>   p == (a,b, 0);
>> 
>> can be considered to be:
>> 
>>   p == (a,b, null-pointer-constant);
>
> Correct.
>
>> provided the embedded 0 can be considered an expression. But since:
>> 
>>   c;
>> 
>> is clearly an expression, then it is not going to be stop being an
>> expression when expanded to:
>> 
>>   (a, b, c);
>
> Yes.
>
>> 
>> Otherwise writing:
>> 
>>   p = 0;       // int*p
>> 
>> can't work because, although 0 is a null-pointer-constant, the composite
>> assignment will embed the 0 so that it is no longer a
>> null-pointer-constant.
>> 
>> But given that the 0 in (a,b,0) appears to be a null-pointer-constant,
>> the machinations required within the rest of the standard to stop that
>> being used legally against pointer types is not at all clear.
>
> There is a big difference between (a, b, 0) and (a ? 0 : 0).  In the
> first case, you have the comma operator, so the type of the expression
> comes entirely from the right hand side.

Note that a constant expression cannot contain a comma operator.

> In the second case, you have a conditional operator.  Look at the rules
> in 6.5.15.  There is no option for both the "b" and "c" parts of a?b:c
> to be null pointer constants (perhaps because that would be a useless
> expression).  The only way to interpret "a ? 0 : 0" to fit the
> constraints is to consider both zeros to be ints.  So you are trying to
> assign the /int/ value 0 to a pointer, not the null pointer constant.

David, I think you're missing something.  A *null pointer constant*
is a kind of expression, but it's not necessarily of pointer type,
and it's not necessarily a constant.  (Remember that a constant, as
opposed to a constant expression, is a single token.)  0 is a null
pointer constant of type int.  It can be explicitly or implicitly
*converted* to a pointer type, yielding a null pointer.

Given that `a` is the name of an object, the expression `a ? 0 : 0` is
not a constant expression, and therefore not an integer constant
expression, and therefore not a null pointer constant.  But the second
and third operands, both of which are simply `0`, are:
    constants
    integer constants
    octal constants
    constant expressions
    integer constant expressions
    null pointer constants
    expressions of type int

`0` is of type int, and is a null pointer constant.
`1 ? 0 : 0` is of type int, and is a null pointer constant.
`a ? 0 : 0` is of type int, and is *not* a null pointer constant.

[...]

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

#112632

FromDavid Brown <david.brown@hesbynett.no>
Date2017-06-19 22:44 +0200
Message-ID<oi9ctg$ro6$1@dont-email.me>
In reply to#112598
On 19/06/17 19:15, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 19/06/17 11:11, bartc wrote:
>>> On 19/06/2017 02:21, David Brown wrote:
>>>> On 19/06/17 01:11, bartc wrote:
>>>
>>>>> (a?b:c) can be a constant expression, provided a, b and c are constants.
> 
> Correction: It can be a constant expression, provided a, b, and c are
> constant expressions.  (I'm assuming a, b, and c are intended to
> represent arbitrary subexpressions and needn't be just identifiers.)

Yes.

> Apart from that quibble, bartc's statement is correct.
> 
>>>> I presume you haven't bothered looking at the standard to see what a
>>>> "constant expression" actually /is/, in the C standards?  And in
>>>> particular, you haven't looked at what an "integer constant
>>>> expression" is?
>>>
>>> The standard says this:
>>>
>>>    "constant-expression:  conditional-expression"
>>>
>>> A condition-expression can be a a?b:c operation.
>>>
>>> But it was hardly necessary to check that, as plenty of programs rely on
>>> using ?: in constant expressions, including that assert macro of a few
>>> weeks back which declared an array parameter bound as either 1 or 0.
>>
>> Yes, and did you also look up "/integer/ constant expression" - the
>> particular type of constant expression Ike referred to?
> 
> David, your previous followup seemed to imply that a conditional
> expression cannot be an integer constant expression.  In fact it can;
> for example `1?0:0` is both an integer constant expression and a null
> pointer constant.

I don't /think/ I implied that, but it is possible - and if so, I was 
mistaken.  I have learned a few more details about integer constant 
expressions during this discussion.  But as Bart pointed out, 
conditional expressions form the heart of common pre-C11 static 
assertion macros, so I have certainly /used/ conditionals (with constant 
expression parts) as integer constant expressions!

> 
> But a conditional expression can be a constant expression only if all
> three of its operands are constant expressions.
> 
<snip>
>> There is a big difference between (a, b, 0) and (a ? 0 : 0).  In the
>> first case, you have the comma operator, so the type of the expression
>> comes entirely from the right hand side.
> 
> Note that a constant expression cannot contain a comma operator.

I see that now.  That is a far simpler explanation than I had been 
thinking of (with the added benefit of being the /correct/ explanation).

> 
>> In the second case, you have a conditional operator.  Look at the rules
>> in 6.5.15.  There is no option for both the "b" and "c" parts of a?b:c
>> to be null pointer constants (perhaps because that would be a useless
>> expression).  The only way to interpret "a ? 0 : 0" to fit the
>> constraints is to consider both zeros to be ints.  So you are trying to
>> assign the /int/ value 0 to a pointer, not the null pointer constant.
> 
> David, I think you're missing something.  A *null pointer constant*
> is a kind of expression, but it's not necessarily of pointer type,
> and it's not necessarily a constant.  (Remember that a constant, as
> opposed to a constant expression, is a single token.)  0 is a null
> pointer constant of type int.  It can be explicitly or implicitly
> *converted* to a pointer type, yielding a null pointer.
> 

OK, that is a distinction that I was a bit vague about.

> Given that `a` is the name of an object, the expression `a ? 0 : 0` is
> not a constant expression, and therefore not an integer constant
> expression, and therefore not a null pointer constant.  But the second
> and third operands, both of which are simply `0`, are:
>      constants
>      integer constants
>      octal constants
>      constant expressions
>      integer constant expressions
>      null pointer constants
>      expressions of type int
> 
> `0` is of type int, and is a null pointer constant.
> `1 ? 0 : 0` is of type int, and is a null pointer constant.
> `a ? 0 : 0` is of type int, and is *not* a null pointer constant.
> 

Thanks for the details and corrections.

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

#112614

FromKeith Thompson <kst-u@mib.org>
Date2017-06-19 12:24 -0700
Message-ID<lnfuevg4qn.fsf@kst-u.example.com>
In reply to#112540
David Brown <david.brown@hesbynett.no> writes:
[...]
> In the second case, you have a conditional operator.  Look at the rules
> in 6.5.15.  There is no option for both the "b" and "c" parts of a?b:c
> to be null pointer constants (perhaps because that would be a useless
> expression).

No, it's because all such cases are already covered.

A null pointer constant is either an expression of integer type, or an
expression of type void*.

If the second and third operands of a conditional operator are both null
pointer constants, there are 3 cases to consider.  If both are of
integer type, or if both are of type void*, then that's already covered
by the existing cases in 6.5.15p3.  If one is is of integer type and the
other is of type void*, that's covered by the 5th bullet:

    - one operand is a pointer and the other is a null pointer constant

In the case of `cond ? 0 : (void*)0`,the "one operand" is (void*)0,
which is a pointer, and the "other" is 0, which is a null pointer
constant.  (I'm reading the phrase "a pointer" as "an expression of
pointer type", which IMHO is how it should have been written.)

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

#112532

FromIke Naar <ike@iceland.freeshell.org>
Date2017-06-19 08:21 +0000
Message-ID<slrn3vfsokf2je.g2t.ike@iceland.freeshell.org>
In reply to#112511
On 2017-06-18, bartc <bc@freeuk.com> wrote:
> On 18/06/2017 21:58, Ike Naar wrote:
>> On 2017-06-18, bartc <bc@freeuk.com> wrote:
>
>>>       p = (a, b, 0);         // (2)
>>>       p = (a ? 0 : 0);       // (3)
>
>> A null pointer constant is a special case of an integer constant expression.
>> 
>> According to 6.6.6:
>>    An integer constant expression 117) shall have integer type and
>>    shall only have operands that are integer constants, enumeration
>>    constants, character constants, sizeof expressions whose results
>>    are integer constants, _Alignof expressions, and floating constants
>>    that are the immediate operands of casts. Cast operators in an
>>    integer constant expression shall only convert arithmetic types
>>    to integer types, except as part of an operand to the sizeof or
>>    _Alignof operator
>> 
>> so neither (a, b, 0) nor (a ? 0 : 0) are integer constant expressions,
>> and therefore not null pointer constants.
>
> (a?b:c) can be a constant expression, provided a, b and c are constants.

True, but that was not the case in your previous example where you wrote

  int a, b;
  int *p;
  p = (a ? 0 : 0);

The 'a' in this expression is clearly not a constant and therefore the
expression (a ? 0 : 0) is not an integer constant expression.

> When a is constant then:
>
>    p = 1 ? 0 : q;         (p, q both int*)
>
> passes in all compilers I tried (even though c - that is, 'q' - is not 
> constant).

The right hand side of an assignment to a pointer-to-int is not
required to be a null pointer constant. As long as the right hand
side of the assignment has the correct type, the assignment has to
pass.

This, for instance

  p = p;

passes too, even though p is not a null pointer constant.

> Although strangely:
>
>    p = 1 ? 0 : 0;
>
> gives a problem in two compilers (even though all elements are constant).

Can you describe the problem (and, if possible, the two compilers)?

> But, the restrictions on being able to use 0 as a null pointer constant 
> only in certain kinds of expressions sound like another quirk.

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

#112536

Frombartc <bc@freeuk.com>
Date2017-06-19 10:17 +0100
Message-ID<yEM1B.58210$y7.9176@fx15.am4>
In reply to#112532
On 19/06/2017 09:21, Ike Naar wrote:
> On 2017-06-18, bartc <bc@freeuk.com> wrote:

>> Although strangely:
>>
>>     p = 1 ? 0 : 0;
>>
>> gives a problem in two compilers (even though all elements are constant).
> 
> Can you describe the problem (and, if possible, the two compilers)?

This code:

     int *p;
     p = (1 ? 0 : 0);

generates this warning on MSVC:

  warning C4047: '=': 'int *' differs in levels of indirection from 'int'

Tiny C says this:

  warning: assignment makes pointer from integer without a cast

-- 
bartc

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

#112596

FromKeith Thompson <kst-u@mib.org>
Date2017-06-19 10:04 -0700
Message-ID<ln8tknhpt6.fsf@kst-u.example.com>
In reply to#112536
bartc <bc@freeuk.com> writes:
> On 19/06/2017 09:21, Ike Naar wrote:
>> On 2017-06-18, bartc <bc@freeuk.com> wrote:
>>> Although strangely:
>>>
>>>     p = 1 ? 0 : 0;
>>>
>>> gives a problem in two compilers (even though all elements are constant).
>> 
>> Can you describe the problem (and, if possible, the two compilers)?
>
> This code:
>
>      int *p;
>      p = (1 ? 0 : 0);
>
> generates this warning on MSVC:
>
>   warning C4047: '=': 'int *' differs in levels of indirection from 'int'

`(1 ? 0 : 0)` is a valid C null pointer constant.

If MSVC is compiling C, it shouldn't issue that warning, though a
compiler can print any non-fatal warnings it likes without affecting
conformance.  If MSVC doesn't treat `(1 ? 0 : 0)` as a null pointer
constant while attempting to act as a conforming C compiler, then
it has a bug.

Note that `(1 ? 0 : 0)` is not a null pointer constant in C++, so
if you're invoking MSVC in C++ mode then the warning is correct.
Likewise if it's compiling some non-standard C dialect, as many C
compilers do by default.

Since you seem uninterested in making sure that you're using
C compilers in conforming mode, can someone else try this, and
perhaps submit a bug report if necessary?

> Tiny C says this:
>
>   warning: assignment makes pointer from integer without a cast

That appears to be a bug that was corrected some time after the
0.9.26 release of tcc.  (The tcc installed by the package manager
on my Ubuntu system identifies itself as 0.9.26, but it's actually
newer than that, and it doesn't issue that warning.)

BTW, tcc seems to be under more active development than I thought.
There have been over 100 commits in the git repo since the beginning
of this year, and over 1000 since release 0.9.26.

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

#112619

FromKeith Thompson <kst-u@mib.org>
Date2017-06-19 12:34 -0700
Message-ID<ln7f07g4a5.fsf@kst-u.example.com>
In reply to#112475
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>A null pointer constant has to be an integer constant
>>expression.

Or such an expression cast to void*.

>   The type of »0« is »int«. But it is kind of like a means
>   that can be used to initialize every scalar type without
>   a cast!
>
> int a        = 0;
> _Bool b      = 0;
> void( *f )() = 0;
> void * p     = 0;
> float c      = 0;
> double x     = 0;
> ...
>
>   , and we can also:
>
> char s[ 10 ] ={ 0 };

Yes, most of these depend on implicit conversions, either from one
arithmetic type to another, or from a null pointer constant to a pointer
type.  The use of { 0 } as an initializer depends on any unspecified
subcomponents being initialized implicitly.  (Expanding on what you
wrote, not disagreeing.)

-- 
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] | [standalone]

Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]

Back to top | Article view | comp.lang.c

csiph-web