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

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

about NULL as a parameter to a libc function

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

Contents

  about NULL as a parameter to a libc function gaoqiang <gaoqiangscut@gmail.com> - 2011-10-28 01:49 -0700
    Re: about NULL as a parameter to a libc function Mark Bluemel <mark_bluemel@pobox.com> - 2011-10-28 10:14 +0100
      Re: about NULL as a parameter to a libc function gaoqiang <gaoqiangscut@gmail.com> - 2011-10-28 03:22 -0700
        Re: about NULL as a parameter to a libc function Mark Bluemel <mark_bluemel@pobox.com> - 2011-10-28 11:29 +0100
          Re: about NULL as a parameter to a libc function Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-29 07:08 +0000
        Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 07:05 -0400
        Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 14:15 -0700
        Re: about NULL as a parameter to a libc function gordonb.4o15x@burditt.org (Gordon Burditt) - 2011-10-28 16:36 -0500
          Re: about NULL as a parameter to a libc function Robert Wessel <robertwessel2@yahoo.com> - 2011-10-28 17:30 -0500
            Re: about NULL as a parameter to a libc function jgharston <jgh@arcade.demon.co.uk> - 2011-10-31 10:40 -0700
        Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-28 22:32 +0000
        Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 06:20 -0700
          Re: about NULL as a parameter to a libc function "BartC" <bc@freeuk.com> - 2011-10-29 15:40 +0100
            Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-30 08:05 -0700
      Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 14:13 -0700
        Re: about NULL as a parameter to a libc function Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-29 15:11 +0300
          Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 06:41 -0700
          Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-29 11:29 -0700
    Re: about NULL as a parameter to a libc function Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-28 02:36 -0700
      Re: about NULL as a parameter to a libc function Mike Manilone <mike@laptop.mike> - 2011-10-28 12:58 +0000
        Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 11:00 -0400
          Re: about NULL as a parameter to a libc function Kenneth Brody <kenbrody@spamcop.net> - 2011-11-03 11:13 -0400
        Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 06:37 -0700
        Re: about NULL as a parameter to a libc function Kenneth Brody <kenbrody@spamcop.net> - 2011-11-03 11:00 -0400
          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 12:54 -0400
            Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 17:08 +0000
              Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 13:18 -0400
                Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 17:28 +0000
                  Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 13:48 -0400
                    Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 17:55 +0000
                      Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 14:12 -0400
                        Re: about NULL as a parameter to a libc function blp@cs.stanford.edu (Ben Pfaff) - 2011-11-03 11:22 -0700
                          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 14:28 -0400
                        Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 19:47 +0000
                          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 16:19 -0400
                        Re: about NULL as a parameter to a libc function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 22:13 -0800
                      Re: about NULL as a parameter to a libc function Ike Naar <ike@sverige.freeshell.org> - 2011-11-03 18:20 +0000
                        Re: about NULL as a parameter to a libc function Ike Naar <ike@sverige.freeshell.org> - 2011-11-03 18:34 +0000
                          Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 19:49 +0000
                            Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 16:21 -0400
                            Re: about NULL as a parameter to a libc function Ike Naar <ike@iceland.freeshell.org> - 2011-11-03 22:19 +0000
                          Re: about NULL as a parameter to a libc function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 22:17 -0800
            Re: about NULL as a parameter to a libc function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 21:19 -0800
      Re: about NULL as a parameter to a libc function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-28 14:26 +0100
        Re: about NULL as a parameter to a libc function Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-10-28 12:46 -0600
        Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 14:19 -0700
          Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 16:37 -0700
    Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 07:22 -0400
      Re: about NULL as a parameter to a libc function Kenneth Brody <kenbrody@spamcop.net> - 2011-11-03 10:40 -0400
        Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 15:10 +0000
        Re: about NULL as a parameter to a libc function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-04 03:03 +0000
    Re: about NULL as a parameter to a libc function Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-28 08:42 -0400
    Re: about NULL as a parameter to a libc function "io_x" <a@b.c.invalid> - 2011-10-28 16:31 +0200
    Re: about NULL as a parameter to a libc function "BartC" <bc@freeuk.com> - 2011-10-28 20:29 +0100
      Re: about NULL as a parameter to a libc function Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-29 14:49 +0300
        Re: about NULL as a parameter to a libc function Ike Naar <ike@sverige.freeshell.org> - 2011-10-29 13:41 +0000
    Re: about NULL as a parameter to a libc function John Gordon <gordon@panix.com> - 2011-10-28 19:53 +0000
      Re: about NULL as a parameter to a libc function "BartC" <bc@freeuk.com> - 2011-10-28 21:13 +0100
        Re: about NULL as a parameter to a libc function John Gordon <gordon@panix.com> - 2011-10-28 20:33 +0000
          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 16:56 -0400
            Re: about NULL as a parameter to a libc function blp@cs.stanford.edu (Ben Pfaff) - 2011-10-28 14:30 -0700
        Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 16:45 -0400
        Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 15:35 -0700
          Re: about NULL as a parameter to a libc function "BartC" <bc@freeuk.com> - 2011-10-29 13:00 +0100
            Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-29 11:26 -0700
              Re: about NULL as a parameter to a libc function "BartC" <bc@freeuk.com> - 2011-10-29 20:24 +0100
                Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-29 14:03 -0700
        Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 07:30 -0700
        Re: about NULL as a parameter to a libc function Kenneth Brody <kenbrody@spamcop.net> - 2011-11-03 11:26 -0400
          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-11-03 12:59 -0400
          Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-11-03 13:42 -0700
    Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-28 20:17 +0000
      Re: about NULL as a parameter to a libc function Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-28 18:51 -0400
    Re: about NULL as a parameter to a libc function Nobody <nobody@nowhere.com> - 2011-10-28 21:40 +0100
      Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-28 17:09 -0400
        Re: about NULL as a parameter to a libc function Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-29 15:03 +0300
          Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-29 09:42 -0400
      Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-28 21:18 +0000
        Re: about NULL as a parameter to a libc function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-28 23:30 +0100
        Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 15:37 -0700
          Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-28 23:47 +0000
            Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-10-28 17:13 -0700
              Re: about NULL as a parameter to a libc function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-29 04:31 +0100
                Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-29 05:42 +0000
                  Re: about NULL as a parameter to a libc function Seebs <usenet-nospam@seebs.net> - 2011-10-30 17:22 +0000
                    Re: about NULL as a parameter to a libc function Patrick Scheible <kkt@zipcon.net> - 2011-10-30 23:43 -0700
                      Re: about NULL as a parameter to a libc function Robert Wessel <robertwessel2@yahoo.com> - 2011-10-31 05:31 -0500
                        Re: about NULL as a parameter to a libc function Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-31 12:42 +0200
                          Re: about NULL as a parameter to a libc function Robert Wessel <robertwessel2@yahoo.com> - 2011-10-31 13:11 -0500
                      Re: about NULL as a parameter to a libc function Seebs <usenet-nospam@seebs.net> - 2011-10-31 17:18 +0000
        Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 07:32 -0700
      Re: about NULL as a parameter to a libc function jacob navia <jacob@spamsink.net> - 2011-10-28 23:41 +0200
        Re: about NULL as a parameter to a libc function Kaz Kylheku <kaz@kylheku.com> - 2011-10-28 22:42 +0000
          Re: about NULL as a parameter to a libc function jacob navia <jacob@spamsink.net> - 2011-10-29 10:09 +0200
            Re: about NULL as a parameter to a libc function Nobody <nobody@nowhere.com> - 2011-10-29 10:11 +0100
              Re: about NULL as a parameter to a libc function Angel <angel+news@spamcop.net> - 2011-10-29 09:42 +0000
              Re: about NULL as a parameter to a libc function jacob navia <jacob@spamsink.net> - 2011-10-29 16:17 +0200
            Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-29 07:39 -0700
              Re: about NULL as a parameter to a libc function jacob navia <jacob@spamsink.net> - 2011-10-29 19:29 +0200
                Re: about NULL as a parameter to a libc function "io_x" <a@b.c.invalid> - 2011-10-29 20:25 +0200
                Re: about NULL as a parameter to a libc function Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-30 08:14 -0700
      Re: about NULL as a parameter to a libc function ImpalerCore <jadill33@gmail.com> - 2011-10-31 18:30 -0700
        Re: about NULL as a parameter to a libc function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 18:21 -0800
      Re: about NULL as a parameter to a libc function Kenneth Brody <kenbrody@spamcop.net> - 2011-11-03 11:31 -0400
        Re: about NULL as a parameter to a libc function Keith Thompson <kst-u@mib.org> - 2011-11-03 13:45 -0700
    Re: about NULL as a parameter to a libc function Jonathan Leffler <jleffler@earthlink.net> - 2011-10-29 23:41 -0700
      Re: about NULL as a parameter to a libc function James Kuyper <jameskuyper@verizon.net> - 2011-10-30 07:13 -0400

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

#12186

On 10/28/2011 08:58 AM, Mike Manilone wrote:
...
> A null pointer always is invalid or protected by OS, so you won't to
> read/write it.

A null pointer is not invalid for assignment or comparison with other
pointers for equality.

> In fact, when you read/write a protected memory, OS (UNIX) will send
> you a message that told you something is wrong.

Not all systems have protected memory, not all systems are UNIX, and not
all systems give you a message when you dereference a null pointer. On
some systems, you might not discover the bad consequences of doing so
until long after the fact.

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

#12590

On 10/28/2011 11:00 AM, James Kuyper wrote:
> On 10/28/2011 08:58 AM, Mike Manilone wrote:
[...]
>> In fact, when you read/write a protected memory, OS (UNIX) will send
>> you a message that told you something is wrong.
>
> Not all systems have protected memory, not all systems are UNIX, and not
> all systems give you a message when you dereference a null pointer. On
> some systems, you might not discover the bad consequences of doing so
> until long after the fact.

Consider MS-DOS.  A "near" NULL pointer would point to the "program segment 
prefix", where some critical data was stored.  A "far" NULL pointer would 
point to the hardware interrupt table.  (Even under Win9x, this was still 
true in the MS-DOS emulator[1].)

Nasty things could happen if you overwrote them.  Sometimes the consequences 
would be immediate, sometimes not until much later.


[1] As I recall, the following code on a Win9x box would immediately 
hard-lock the system:

     void far *vector = MAKE_FP(0,48); /* Makes a far pointer to 0000:0030 */
     void far *int21 = *(void far **)vector;

     *(long far *)int21 = 0;

Basically, it overwrites the first 4 bytes of the INT21 system call handler.

-- 
Kenneth Brody

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

#12233

On Oct 28, 3:59 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 10/28/2011 08:58 AM, Mike Manilone wrote:
> ...
>
> > A null pointer always is invalid or protected by OS, so you won't to
> > read/write it.
>
> A null pointer is not invalid for assignment or comparison with other
> pointers for equality.
>
> > In fact, when you read/write a protected memory, OS (UNIX) will send
> > you a message that told you something is wrong.
>
> Not all systems have protected memory, not all systems are UNIX, and not
> all systems give you a message when you dereference a null pointer. On
> some systems, you might not discover the bad consequences of doing so
> until long after the fact.

not even all UNIX have protected memory. I believe some Crays didn't
have virtual memory and so possibly didn't have protected memory. The
C compiler for HPUX made it an option whether dereferencing a null
pointer gave a segmentaion error. I've no idea why (kernel
programming?).

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

#12588

On 10/28/2011 8:58 AM, Mike Manilone wrote:
[...]
> A null pointer always is invalid or protected by OS, so you won't to
> read/write it.

Well, it's "invalid" as far as C is concerned.  Nothing in C that returns a 
pointer to a valid object will ever return a null pointer.  (Except as a 
"special case".  However that "special case" will never be a pointer to a 
valid object.)

Whether it's "valid" as far as the O/S and hardware are concerned is outside 
the realm of the C language itself.

Note, too, that it's perfectly acceptable (as far as the C language itself 
is concerned) to have NULL point to a "valid" address, as long as no valid 
object can be at that address.  For example, it would be legal (AFAIK) for 
an implementation to do something like this:

     extern char __NULL__;
     #define NULL ((void *)(&__NULL__))

> In fact, when you read/write a protected memory, OS (UNIX) will send
> you a message that told you something is wrong.

I do know that some Unix systems actually have a "page" of all-bits-zero at 
the address pointed to by NULL.  The memory is read-only, but it is there, 
and therefore things like strlen(NULL) or strcpy(buffer,NULL) will "work", 
in the sense that *(char*)NULL=='\0', and therefore (char*)NULL is read the 
same as an empty string.

> If you use a different it's not a problem (if the OS don't protect any
> memory). You can read/write it correctly.

I guess it depends on what you mean by "correctly".

Of course, it's also acceptable for an implementation to define what it 
means to dereference a null pointer.

-- 
Kenneth Brody

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

#12597

On 11/03/2011 11:00 AM, Kenneth Brody wrote:
...
> Note, too, that it's perfectly acceptable (as far as the C language itself 
> is concerned) to have NULL point to a "valid" address, as long as no valid 
> object can be at that address. ...

That is correct.

> ...  For example, it would be legal (AFAIK) for 
> an implementation to do something like this:
> 
>      extern char __NULL__;
>      #define NULL ((void *)(&__NULL__))

No, NULL is required to expand into a null pointer constant. A null
pointer constant is either "An integer constant expression with the
value 0, or such an expression cast to type void *," (6.3.2.3p3).

ICEs must have integer type; &__NULL__ has a pointer type. The operands
of an ICE "shall only have operands that are integer constants,
enumeration constants, character constants, sizeof expressions whose
results are integer constants, and floating constants that are the
immediate operands of casts." (6.6p6). __NULL__ qualifies as none of
those things. While "an implementation may accept other forms of
constant expressions" (6.6p10), those other forms will, by definition of
"other", not have the right form to qualify as any of the specific types
of constants specified in 6.6p6.

What is permitted is for NULL to expand into a particular form of null
pointer constant that will be converted, when it occurs in a pointer
context, into a pointer which happens to point at __NULL__. It would
require a fair amount of compiler magic, however, to make that happen
without also having 0 == &__NULL__.

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

#12600

On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
> On 11/03/2011 11:00 AM, Kenneth Brody wrote:
> ...
>> Note, too, that it's perfectly acceptable (as far as the C language itself 
>> is concerned) to have NULL point to a "valid" address, as long as no valid 
>> object can be at that address. ...
>
> That is correct.
>
>> ...  For example, it would be legal (AFAIK) for 
>> an implementation to do something like this:
>> 
>>      extern char __NULL__;
>>      #define NULL ((void *)(&__NULL__))
>
> No, NULL is required to expand into a null pointer constant. A null
> pointer constant is either "An integer constant expression with the
> value 0, or such an expression cast to type void *," (6.3.2.3p3).

Since __NULL__ is an external name in the implementation space, and this is
supposed to be some implementation's definition of NULL anyway, those rules are
moot.  The implementation could arrange for &__NULL__ to be a constant
expression to make this all work.

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

#12601

On 11/03/2011 01:08 PM, Kaz Kylheku wrote:
> On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
>> On 11/03/2011 11:00 AM, Kenneth Brody wrote:
...
>>> ...  For example, it would be legal (AFAIK) for 
>>> an implementation to do something like this:
>>>
>>>      extern char __NULL__;
>>>      #define NULL ((void *)(&__NULL__))
>>
>> No, NULL is required to expand into a null pointer constant. A null
>> pointer constant is either "An integer constant expression with the
>> value 0, or such an expression cast to type void *," (6.3.2.3p3).
> 
> Since __NULL__ is an external name in the implementation space, and this is
> supposed to be some implementation's definition of NULL anyway, those rules are
> moot.  The implementation could arrange for &__NULL__ to be a constant
> expression to make this all work.

I don't think your argument is valid. Where is it stated in the standard
that those conditions render those rules moot?  If your argument were
valid, it would render the requirement that NULL expand into a null
pointer constant (7.17p3) meaningless. I doubt that it was intended to
be meaningless.

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

#12602

On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
> On 11/03/2011 01:08 PM, Kaz Kylheku wrote:
>> On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
>>> On 11/03/2011 11:00 AM, Kenneth Brody wrote:
> ...
>>>> ...  For example, it would be legal (AFAIK) for 
>>>> an implementation to do something like this:
>>>>
>>>>      extern char __NULL__;
>>>>      #define NULL ((void *)(&__NULL__))
>>>
>>> No, NULL is required to expand into a null pointer constant. A null
>>> pointer constant is either "An integer constant expression with the
>>> value 0, or such an expression cast to type void *," (6.3.2.3p3).
>> 
>> Since __NULL__ is an external name in the implementation space, and this is
>> supposed to be some implementation's definition of NULL anyway, those rules are
>> moot.  The implementation could arrange for &__NULL__ to be a constant
>> expression to make this all work.
>
> I don't think your argument is valid. Where is it stated in the standard
> that those conditions render those rules moot?  If your argument were
> valid, it would render the requirement that NULL expand into a null
> pointer constant (7.17p3) meaningless. I doubt that it was intended to
> be meaningless.

6.6 10 An implementation may accept other forms of constant expressions.

This sort of thing only makes a difference to highly contrived program
which does something like this:

   #define STR(X) #X
   #define STRE(X) STR(X)

   if (!is_null_pointer_constant(STRE(NULL))) {
     printf("unconventional null pointer constant");
   } 

Where is_null_pointer_constant is a function which lexically analyzes
and parses the stringified expansion of NULL, and validates what kind
of expression it is.

Since implementation can accept other forms of constant expressions,
this program cannot conclude that the implementation is nonconforming
(and is itself not maximally portable since its output depends on
the implementation.)

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

#12603

On 11/03/2011 01:28 PM, Kaz Kylheku wrote:
> On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
>> On 11/03/2011 01:08 PM, Kaz Kylheku wrote:
>>> On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
>>>> On 11/03/2011 11:00 AM, Kenneth Brody wrote:
>> ...
>>>>> ...  For example, it would be legal (AFAIK) for 
>>>>> an implementation to do something like this:
>>>>>
>>>>>      extern char __NULL__;
>>>>>      #define NULL ((void *)(&__NULL__))
>>>>
>>>> No, NULL is required to expand into a null pointer constant. A null
>>>> pointer constant is either "An integer constant expression with the
>>>> value 0, or such an expression cast to type void *," (6.3.2.3p3).
>>>
>>> Since __NULL__ is an external name in the implementation space, and this is
>>> supposed to be some implementation's definition of NULL anyway, those rules are
>>> moot.  The implementation could arrange for &__NULL__ to be a constant
>>> expression to make this all work.
>>
>> I don't think your argument is valid. Where is it stated in the standard
>> that those conditions render those rules moot?  If your argument were
>> valid, it would render the requirement that NULL expand into a null
>> pointer constant (7.17p3) meaningless. I doubt that it was intended to
>> be meaningless.
> 
> 6.6 10 An implementation may accept other forms of constant expressions.

Yes, I've seen that argument before, and addressed it in one of the
paragraphs you've snipped from one of my earlier messages. Those forms
are "other" than "integer constants, enumeration constants, character
constants, ... and floating constants", which are the only kinds allowed
in ICE. The "other forms of constant expressions" that "an
implementation may accept" don't meet the requirements of any of the
standard-named categories of constants, so they only fall into the
"other" category. They can be used anywhere that the standard requires a
constant expression, without specifying a particular type of constant
expression; they cannot be used as when a specific type of constant
expression is required, as is indeed the case for null pointer
constants, which require an integer constant expression.

Note that an implementation doesn't need to use 6.6p10 to make &__NULL__
qualify as a constant expression; it already qualifies under the
category "address constant expression" (6.6p9).

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

#12604

On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
> Note that an implementation doesn't need to use 6.6p10 to make &__NULL__
> qualify as a constant expression; it already qualifies under the
> category "address constant expression" (6.6p9).

&__NULL__ can be a contant integral expression evaluating to zero, if the
implementors so want.

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

#12605

On 11/03/2011 01:55 PM, Kaz Kylheku wrote:
> On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
>> Note that an implementation doesn't need to use 6.6p10 to make &__NULL__
>> qualify as a constant expression; it already qualifies under the
>> category "address constant expression" (6.6p9).
> 
> &__NULL__ can be a contant integral expression evaluating to zero, if the
> implementors so want.

Perhaps, though I doubt that the fact that __NULL__ is a reserved word
gives an implementation permission to ignore the standard semantics of
'&', which can never appear as the first token of an expression with
integer type. If the __NULL__ occurred in user code, it would be a
different matter - but if the user code contains NULL, the
implementation's not allowed to invoke "undefined behavior" as a result
of a feature of that expansion, as an excuse to violate the
standard-defined semantics of '&'.

However, null pointer constants are defined as involving an "integer
constant expression", a phrase whose meaning as a whole is defined in
6.6p6. That definition is not merely the combination of the definitions
of integer, constant, and expression - many constant expressions with
integral type fail to qualify as integer constant expressions.

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

#12608

James Kuyper <jameskuyper@verizon.net> writes:

> Perhaps, though I doubt that the fact that __NULL__ is a reserved word
> gives an implementation permission to ignore the standard semantics of
> '&', which can never appear as the first token of an expression with
> integer type. 

Did you mean to add more qualifiers?  I believe that &x - &x is
an expression with integer type, for appropriately defined 'x'.
-- 
"Welcome to the wonderful world of undefined behavior, where the demons
 are nasal and the DeathStation users are nervous." --Daniel Fox

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

#12609

On 11/03/2011 02:22 PM, Ben Pfaff wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> 
>> Perhaps, though I doubt that the fact that __NULL__ is a reserved word
>> gives an implementation permission to ignore the standard semantics of
>> '&', which can never appear as the first token of an expression with
>> integer type. 
> 
> Did you mean to add more qualifiers?  I believe that &x - &x is
> an expression with integer type, for appropriately defined 'x'.

You've got a point there. I stated my point too generally, and I'm not
sure how to reword it to cover such issues. I'll concede that &__NULL__
could have integer type if __NULL__ were a macro whose expansion had a
form like that. But that's not the meaning for __NULL__ that was suggested.

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

#12614

On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
> On 11/03/2011 01:55 PM, Kaz Kylheku wrote:
>> On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
>>> Note that an implementation doesn't need to use 6.6p10 to make &__NULL__
>>> qualify as a constant expression; it already qualifies under the
>>> category "address constant expression" (6.6p9).
>> 
>> &__NULL__ can be a contant integral expression evaluating to zero, if the
>> implementors so want.
>
> Perhaps, though I doubt that the fact that __NULL__ is a reserved word
> gives an implementation permission to ignore the standard semantics of

__NULL__ being a reserved word means that demons can fly out of the
programmer's nose when it is used.

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

#12619

On 11/03/2011 03:47 PM, Kaz Kylheku wrote:
> On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
>> On 11/03/2011 01:55 PM, Kaz Kylheku wrote:
>>> On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
>>>> Note that an implementation doesn't need to use 6.6p10 to make &__NULL__
>>>> qualify as a constant expression; it already qualifies under the
>>>> category "address constant expression" (6.6p9).
>>>
>>> &__NULL__ can be a contant integral expression evaluating to zero, if the
>>> implementors so want.
>>
>> Perhaps, though I doubt that the fact that __NULL__ is a reserved word
>> gives an implementation permission to ignore the standard semantics of
> 
> __NULL__ being a reserved word means that demons can fly out of the
> programmer's nose when it is used.

No, that would be true only if the user code "declares or defines"
__NULL__ (7.1.3p2). Using NULL counts as neither a declaration nor a
definition of __NULL__. Since, in most contexts, using an identifier
that has neither been declared or defined is either a syntax error or a
constraint violation, user code which uses __NULL__ in any way would
also be a problem, though for a different reason.

However, for the purposes of 7.1.3p2, the expansion of NULL wouldn't
count as such a declaration or definition of __NULL__ even if the
expansion did happen to contain one, because the existence of that
feature is the implementation's responsibility, and it's the
implementation's additional responsibility to ensure that whatever NULL
expands to causes no such problems for strictly conforming code.

While that expansion may contain features that would render the behavior
undefined if they occurred in user code, when they occur in the
expansion of a C standard macro, the behavior is not allowed to be
anything inconsistent with what the C standard specifies for that macro.
What the standard specifies for NULL is a null pointer constant, and it
does not specify any relaxation of the rules determining what a null
pointer constant is.

In any event, the suggested implementation of NULL contained neither a
declaration nor a definition of __NULL__, just a use of __NULL__ as an
operand in an address constant expression. Since the suggested
implementation of NULL also specified that a  declaration for __NULL__
appeared inside the standard header, it also doesn't count as a use of
an undeclared identifier.

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

#16175

James Kuyper <jameskuyper@verizon.net> writes:

> [snip]
>
> However, null pointer constants are defined as involving an "integer
> constant expression", a phrase whose meaning as a whole is defined in
> 6.6p6.  [snip]

You are misunderstanding the license granted by 6.6p10, which
allows other forms of the various subtypes of constant expression,
including integer constant expressions.  Again, look at the
statements made in the Rationale document.

Another problem with your theory (ie, that 6.6p10 applies only to
generic constant expressions, not to any of the subtypes listed in
6.6p10) is that then 6.6p10 wouldn't change anything.  In all cases
where a program is required to use a constant expression, it is
required to use one of the subtypes of constant expression;
allowing 'other forms of constant expressions' only for "generic"
constant expressions, but not for the subtypes, is meaningless
because it would have no effect.  (An argument could be made that
limiting 6.6p10 to just generic CE's would allow an implementation
to define some of the symbols given in 5.2.4.2.2 in such a way that
some otherwise-legal programs would exhibit constraint violations;
surely such a result cannot be the motivation for the statement in
6.6p10.)  Since there is no reason to grant a meaningless or
useless licence, the statement in 6.6p10 must mean something other
than what you think it means.

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

#12607

On 2011-11-03, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2011-11-03, James Kuyper <jameskuyper@verizon.net> wrote:
>> Note that an implementation doesn't need to use 6.6p10 to make &__NULL__
>> qualify as a constant expression; it already qualifies under the
>> category "address constant expression" (6.6p9).
>
> &__NULL__ can be a contant integral expression evaluating to zero, if the
> implementors so want.


-- 
ike@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org

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

#12610

On 2011-11-03, Ike Naar <ike@sverige.freeshell.org> wrote:
> On 2011-11-03, Kaz Kylheku <kaz@kylheku.com> wrote:
>> &__NULL__ can be a contant integral expression evaluating to zero, if the
>> implementors so want.

Sorry for my previous post which did not contain any new text.
Something went wrong during posting.

In the meantime, James has already submitted a response
similar to what I was trying to submit:
Kaz's quoted statement about "contant integral expression" contradicts
6.6 p6 which states that an integer constant expression shall have
integer type, while &__NULL__ has type pointer-to-char.

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

#12615

On 2011-11-03, Ike Naar <ike@sverige.freeshell.org> wrote:
> On 2011-11-03, Ike Naar <ike@sverige.freeshell.org> wrote:
>> On 2011-11-03, Kaz Kylheku <kaz@kylheku.com> wrote:
>>> &__NULL__ can be a contant integral expression evaluating to zero, if the
>>> implementors so want.
>
> Sorry for my previous post which did not contain any new text.
> Something went wrong during posting.
>
> In the meantime, James has already submitted a response
> similar to what I was trying to submit:
> Kaz's quoted statement about "contant integral expression" contradicts
> 6.6 p6 which states that an integer constant expression shall have
> integer type, while &__NULL__ has type pointer-to-char.

On a DeathStation 9000, &__NULL__ overwrites the partition table on your
root disk. :)

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

#12620

On 11/03/2011 03:49 PM, Kaz Kylheku wrote:
> On 2011-11-03, Ike Naar <ike@sverige.freeshell.org> wrote:
>> On 2011-11-03, Ike Naar <ike@sverige.freeshell.org> wrote:
>>> On 2011-11-03, Kaz Kylheku <kaz@kylheku.com> wrote:
>>>> &__NULL__ can be a contant integral expression evaluating to zero, if the
>>>> implementors so want.
>>
>> Sorry for my previous post which did not contain any new text.
>> Something went wrong during posting.
>>
>> In the meantime, James has already submitted a response
>> similar to what I was trying to submit:
>> Kaz's quoted statement about "contant integral expression" contradicts
>> 6.6 p6 which states that an integer constant expression shall have
>> integer type, while &__NULL__ has type pointer-to-char.
> 
> On a DeathStation 9000, &__NULL__ overwrites the partition table on your
> root disk. :)

Except when it is found in the expansion of a standard macro. Otherwise
it's not fully conforming, and as we all know, the DS9000 is a paragon
of conformance. :-)

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

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

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

csiph-web