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

Groups > comp.lang.c++ > #120928 > unrolled thread

Is EXIT_SUCCESS/EXIT_FAILURE necessary?

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

Contents

  Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-20 11:02 +0800
    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-20 09:22 +0200
      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 08:27 +0000
        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 13:47 +0000
          Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 15:05 +0000
            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 15:45 +0000
              Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-20 16:41 +0000
      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 13:37 -0800
        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 22:11 +0000
          Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 14:33 -0800
            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 23:03 +0000
              Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 15:57 -0800
            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-20 15:58 -0800
              Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:43 +0000
                Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-21 16:07 +0000
                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 17:55 +0000
                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-22 09:30 +0100
                      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-22 11:10 -0800
                        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@dastardlyhq.com - 2024-11-23 11:36 +0000
                      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-22 12:26 -0800
                        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-22 12:49 -0800
                        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-22 23:26 +0000
                        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-23 13:07 +0100
                          Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 13:55 -0800
                            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-01 20:57 -0800
                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-22 09:55 +0000
                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-26 04:21 -0800
                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 11:57 -0500
                Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 11:31 -0500
                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-22 12:36 -0800
                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-22 16:53 -0500
                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-24 12:57 +0800
                      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 14:03 -0800
                        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-26 12:21 +0800
                          Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-27 16:23 +0800
                            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastartdlyHQ.org - 2024-11-27 08:26 +0000
                              Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-27 18:48 +0800
                                Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-27 15:39 +0200
                                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 13:54 +0000
                                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-27 17:24 +0200
                                      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 16:12 +0000
                                        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-27 13:00 -0500
                                          Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:23 +0000
                                          Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:06 +0200
                                            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-28 08:08 -0500
                                        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:58 -0500
                                          Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-27 19:46 -0800
                                          Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:26 +0000
                                            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 13:03 +0200
                                              Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ralf Fassel <ralfixx@gmx.de> - 2024-11-28 12:15 +0100
                                                Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 13:36 +0200
                                                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ralf Fassel <ralfixx@gmx.de> - 2024-11-28 14:12 +0100
                                              Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Richard Damon <richard@damon-family.org> - 2024-11-28 07:50 -0500
                                              Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:19 +0200
                                                Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 15:12 +0000
                                                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 17:36 +0200
                                                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? David Brown <david.brown@hesbynett.no> - 2024-11-28 16:43 +0100
                                                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 15:59 +0000
                                                      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-28 10:19 -0800
                                                Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-28 22:41 +0200
                                                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-29 00:21 +0200
                                                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-29 00:59 +0200
                                                      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-29 01:20 +0200
                                            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-28 17:18 -0500
                                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-27 19:01 +0200
                                      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-28 08:22 +0000
                                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-27 11:00 -0800
                                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:57 -0500
                                Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Muttley@DastardlyHQ.org - 2024-11-27 13:52 +0000
                                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-27 14:54 -0500
                                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-28 15:27 +0200
                              Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-27 15:30 +0200
                          Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-28 18:32 -0800
                    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 14:00 -0800
                      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-25 14:15 -0800
                      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-01 21:00 -0800
                  Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-26 04:26 -0800
            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-20 23:20 -0500
          Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-20 17:32 -0800
            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? red floyd <no.spam.here@its.invalid> - 2024-11-20 22:56 -0800
              Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:52 +0000
            Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:51 +0000
    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 13:44 +0000
      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-20 22:57 +0800
        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Michael S <already5chosen@yahoo.com> - 2024-11-20 17:23 +0200
    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-20 23:09 -0500
      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 13:52 +0000
      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? wij <wyniijj5@gmail.com> - 2024-11-21 22:45 +0800
    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Rosario19 <Ros@invalid.invalid> - 2024-11-25 22:20 +0100
      Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-11-26 10:20 +0100
        Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Rosario19 <Ros@invalid.invalid> - 2024-11-30 16:52 +0100
    Re: Is EXIT_SUCCESS/EXIT_FAILURE necessary? Andrey Tarasevich <noone@noone.net> - 2025-02-15 16:21 -0800

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

#120983

On 11/22/2024 12:26 PM, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> However, I can't see a justification for claiming that "if (p)" works
>> as expected for any C implementation.  I might be missing something,
>> and of course real C implementations will support it as you would
>> expect.  In C++, "if (p)" converts "p" to bool, but in C, it converts
>> it to "int". And while you are guaranteed that converting an integer
>> constant expression of value 0 to a pointer type will give you a null
>> pointer, you are not guaranteed that a null pointer, converted to an
>> int, will give 0.  (And int variables and other expressions of int
>> type which happen to contain the value 0, are not guaranteed to give
>> null pointers when converting to a pointer type - only /constant/
>> expressions get that treatment.)
> 
> Yes, you're missing something.
> 
>      some_type *p;

p can be anything here... Right?

>      if (p) do_something();

scary code...


> N1570 6.8.4: `do_something();` is executed if p "compares unequal to 0",
> so `if (p)` is equivalent to `if (p != 0)`.


[...]

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

#120986

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>David Brown <david.brown@hesbynett.no> writes:
>[...]

  >>Scott Lurndal argued that testing for a null pointer using if (!pointer)
  >> is iffy and poor coding practice.

>> What counts as "bad coding practice" is a much more subjective matter.
>
>Indeed.  I would write `if (foo)` only if foo is of type bool/_Bool (or
>is "logically Boolean", such as a C int value with no meaninful
>distinction among non-zero values).  I would write:
>
>    - `if (foo != NULL)` or `if (foo != nullptr)` for a pointer;
>    - `if (foo != '\0')` for a character (or '\0L');
>    - `if (foo != 0)` for an integer that doesn't denote a character or
>      boolean value (or possibly `0L` et al);
>    - `if (foo != 0.0)` for a floating-point value (or possibly
>      0.0f or 0.0L).

I've also followed these guidelines since I started programming in
C and later C++ some forty years ago.   It seems natural to me at
this point.  I recognize that other programmers prefer the more
abbreviated form.

>
>But that's my own preference, and I don't have any problem reading code
>written by people with different preferences.  I recognize that more
>agressive use of `if (foo)` is a common idiom, one I'll follow myself if
>I'm subjected to a coding standard that requires it.

Indeed.

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

#120992

On 22/11/2024 21:26, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> However, I can't see a justification for claiming that "if (p)" works
>> as expected for any C implementation.  I might be missing something,
>> and of course real C implementations will support it as you would
>> expect.  In C++, "if (p)" converts "p" to bool, but in C, it converts
>> it to "int". And while you are guaranteed that converting an integer
>> constant expression of value 0 to a pointer type will give you a null
>> pointer, you are not guaranteed that a null pointer, converted to an
>> int, will give 0.  (And int variables and other expressions of int
>> type which happen to contain the value 0, are not guaranteed to give
>> null pointers when converting to a pointer type - only /constant/
>> expressions get that treatment.)
> 
> Yes, you're missing something.
> 
>      some_type *p;
>      if (p) do_something();
> 
> N1570 6.8.4: `do_something();` is executed if p "compares unequal to 0",
> so `if (p)` is equivalent to `if (p != 0)`.
> 

Ah, yes - thanks!

> N1570 6.5.10: "If one operand is a pointer and the other is a null
> pointer constant, the null pointer constant is converted to the type of
> the pointer."  0 is a null pointer constant, so it's converted to type
> `some_type*`, yielding a null pointer value of that type.
> 
> In `if (p)`, p is not converted to int.  It's compared for inequality to
> 0, and the result of that comparison is of type int.
> 

That is interesting - I had been assuming the controlling expression of 
"if" was converted to type "int" in C, in the way that it is converted 
to "bool" in C++.  I guess I should not have been making assumptions!
	


>> So for C, "if (p)" appears to be "iffy" in theory, but fine in
>> practice.   "if (!p)" is fine, as is "if (!!p)" and "if ((bool) p)".
>> For C++, "if (p)" is solid.
>>
>> (If anyone can point to what I am missing that makes "if (p)" safe in
>> C, I'd be glad to hear about it.)
>>
>> What counts as "bad coding practice" is a much more subjective matter.
> 
> Indeed.  I would write `if (foo)` only if foo is of type bool/_Bool (or
> is "logically Boolean", such as a C int value with no meaninful
> distinction among non-zero values).  I would write:
> 
>      - `if (foo != NULL)` or `if (foo != nullptr)` for a pointer;
>      - `if (foo != '\0')` for a character (or '\0L');
>      - `if (foo != 0)` for an integer that doesn't denote a character or
>        boolean value (or possibly `0L` et al);
>      - `if (foo != 0.0)` for a floating-point value (or possibly
>        0.0f or 0.0L).
> 
> But that's my own preference, and I don't have any problem reading code
> written by people with different preferences.  I recognize that more
> agressive use of `if (foo)` is a common idiom, one I'll follow myself if
> I'm subjected to a coding standard that requires it.
> 

I am quite happy to write "if (p) ... " for checking a pointer - but I 
would write the code and name variables in a way that makes it entirely 
clear that "p" is a pointer.  Code clarity is the main point.  (I am 
also happy to check my std::optional<> variables with "if (xp) ..." 
style checks.)

I don't like to use 0 for a null pointer constant, either for setting or 
for comparison - I'm glad to see nullptr has made it into C as well as C++.

But to my mind, "if (p)" is asking "Is p a pointer to something?", while 
"if (p != nullptr)" is asking "Is p not equal to nullptr?".  The first 
version seems a more accurate representation of what I actually want, 
while the second is somewhat indirect.  I am testing a characteristic of 
the expression, rather than trying to see what it is not.

I don't know if there are any real-world implementations (of C or C++) 
with more than one representation for null pointers, but null pointers 
are somewhat special.  "if (x == y)" compares for equality of two 
values, unless one of these is a pointer and the other is a null pointer 
constant - then the comparison is more of a classification, checking if 
the pointer is in the set of null pointer values.

Once you move beyond just C-style pointers, testing by contextual 
conversion to bool becomes a lot more versatile than comparing against a 
specific "magic" value.  I would check std::unique_ptr<> values with "if 
(p)" rather than "if (p.get() != nullptr)", and std::expected<> with "if 
(x)" rather than "if (x.has_value())".


Of course I am happy to read code using either convention, and 
consistency of style is probably more important than either choice. 
Whatever makes the meaning of the code clearest, and reduces the risk of 
mistakes or misunderstandings, is the best choice.


> (C tends to use int for character and Boolean values.  C++ tends not to
> do that as much, though you can still write C-style code in C++, and C++
> includes (most of) the C standard library.)
> 
> I didn't cross-post this to comp.lang.c, but we might consider doing so
> if the discussion continues into C-specific content.
> 

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

#121016

David Brown <david.brown@hesbynett.no> writes:
[...]
> I don't know if there are any real-world implementations (of C or C++)
> with more than one representation for null pointers, but null pointers
> are somewhat special.  "if (x == y)" compares for equality of two
> values, unless one of these is a pointer and the other is a null
> pointer constant - then the comparison is more of a classification,
> checking if the pointer is in the set of null pointer values.
[...]

I'd say that a null pointer of a given type is a single *value* that may
or may not have multiple *representations*.  If it does have multiple
representations, all of them compare equal.

And in practice, having multiple representations for a null pointer (of
a given type) isn't much more likely than having multiple
representations for 42.

The "set of null pointer values" you mentioned is just a single value.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121118

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> David Brown <david.brown@hesbynett.no> writes:
> [...]
>
>> I don't know if there are any real-world implementations (of C or
>> C++) with more than one representation for null pointers, but
>> null pointers are somewhat special.  "if (x == y)" compares for
>> equality of two values, unless one of these is a pointer and the
>> other is a null pointer constant - then the comparison is more of
>> a classification, checking if the pointer is in the set of null
>> pointer values.
>
> [...]
>
> I'd say that a null pointer of a given type is a single *value*
> that may or may not have multiple *representations*.  [...]

That's a point of view, but it isn't anything more than that.  The
abstract value space of pointers is not well defined.  By contrast,
the abstract value space of an integer data type, such as int, is
well defined.  Two pointers can compare equal and yet not be the
same pointer.  There is no reason the same relationship can't
hold for null pointers.  (In both of the last two sentences the
word "pointer" may be read as "pointer value".)

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

#120973

On Thu, 21 Nov 2024 17:55:49 GMT
scott@slp53.sl.home (Scott Lurndal) boring babbled:
>Muttley@DastartdlyHQ.org writes:
>>On Thu, 21 Nov 2024 13:43:30 GMT
>>scott@slp53.sl.home (Scott Lurndal) boring babbled:
>>>"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>On 11/20/2024 2:33 PM, Chris M. Thomasson wrote:
>>>>> On 11/20/2024 2:11 PM, Scott Lurndal wrote:
>>>
>>>>
>>>>Actually, for some reason, this makes me think of nullptr = 0 = NULL wrt 
>>>>NULL can be 0xdeadbeefbeefdead?
>>>>
>>>
>>>I've worked with systems where the NULL pointer value was not zero.
>>>
>>>That's why C has a symbolic constant for NULL.
>>
>>Thats a bit iffy given the number of devs - and I include myself - who often
>use
>>!<whatever> in place of <whatever> == NULL and similarly <whatever> instead
>>of <whatever> != NULL.
>
>No, it's not iffy, that's just bad coding practice on your part.

Its entirely standard coding practice.

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

#121025

scott@slp53.sl.home (Scott Lurndal) writes:

> Muttley@DastartdlyHQ.org writes:
>
>> On Thu, 21 Nov 2024 13:43:30 GMT
>> scott@slp53.sl.home (Scott Lurndal) boring babbled:
>>
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> On 11/20/2024 2:33 PM, Chris M. Thomasson wrote:
>>>>
>>>>> On 11/20/2024 2:11 PM, Scott Lurndal wrote:
>>>>
>>>> Actually, for some reason, this makes me think of nullptr = 0 =
>>>> NULL wrt NULL can be 0xdeadbeefbeefdead?
>>>
>>> I've worked with systems where the NULL pointer value was not
>>> zero.
>>>
>>> That's why C has a symbolic constant for NULL.
>>
>> Thats a bit iffy given the number of devs - and I include myself -
>> who often use !<whatever> in place of <whatever> == NULL and
>> similarly <whatever> instead of <whatever> != NULL.
>
> No, it's not iffy, that's just bad coding practice on your part.

That is a commonly held view, but I've never seen any defense
offered for it other than folklore.

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

#120977

Muttley@DastartdlyHQ.org writes:
>On Thu, 21 Nov 2024 13:43:30 GMT
>scott@slp53.sl.home (Scott Lurndal) boring babbled:
...
>>I've worked with systems where the NULL pointer value was not zero.
>>
>>That's why C has a symbolic constant for NULL.
>
>Thats a bit iffy given the number of devs - and I include myself - who often use
>!<whatever> in place of <whatever> == NULL and similarly <whatever> instead
>of <whatever> != NULL.

Regardless of a whether null pointers have any bits set, any integer
constant expression with a value of 0 qualifies as a null pointer
constant. NULL is required to expand into an NPC, and therefore cannot
expand into an integer expression with a non-zero value. All such
expressions must, if they occur in a pointer context, be converted to
null pointers of the appropriate type.
Null pointers always compare equal to null pointer constants, because in
the context of such comparisons, null pointer constants get converted to
null pointers of the appropriate type, and all null pointers compare equal.

In every logical context (such as x in if(x), for(...; x; ...),
while(x), do ... while (x), !x, x1&&x2, x1||x2, x?a:b, etc),pointers are
converted to bool, Null pointers converted to bool always result in a
value of false, regardless o how they are represented.

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

#120976

On 11/21/24 08:43, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 11/20/2024 2:33 PM, Chris M. Thomasson wrote:
>>> On 11/20/2024 2:11 PM, Scott Lurndal wrote:
> 
>>
>> Actually, for some reason, this makes me think of nullptr = 0 = NULL wrt 
>> NULL can be 0xdeadbeefbeefdead?
>>
> 
> I've worked with systems where the NULL pointer value was not zero.
> 
> That's why C has a symbolic constant for NULL.

Not really - that's the reason why C has special handling for null
pointer constants. Even on systems where null pointers are represented
by a bit pattern with one or more bits set, a null pointer constant can
still be 0, and if used in a pointer context, must be converted to a
null pointer. The main reason for NULL is that some implementations
thought it would be better for type safety to use (void*)0.

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

#120982

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 11/21/24 08:43, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 11/20/2024 2:33 PM, Chris M. Thomasson wrote:
>>>> On 11/20/2024 2:11 PM, Scott Lurndal wrote:
>> 
>>>
>>> Actually, for some reason, this makes me think of nullptr = 0 = NULL wrt 
>>> NULL can be 0xdeadbeefbeefdead?
>>>
>> 
>> I've worked with systems where the NULL pointer value was not zero.
>> 
>> That's why C has a symbolic constant for NULL.
>
> Not really - that's the reason why C has special handling for null
> pointer constants. Even on systems where null pointers are represented
> by a bit pattern with one or more bits set, a null pointer constant can
> still be 0, and if used in a pointer context, must be converted to a
> null pointer. The main reason for NULL is that some implementations
> thought it would be better for type safety to use (void*)0.

`(void*)0` is a null pointer constant in C but not in C++, because C++
has no implicit conversion from void* to other pointer types.

0 is a null pointer constant, and a valid expansion for NULL, in both C
and C++.

Note that `(void*)0` is a C null pointer constant, but not a valid
expansion for NULL.  It needs to be `((void*)0)`.  (A painfully literal
reading of the C standard up to and including C17 suggests that a
parenthesized null pointer constant is not a null pointer constant, but
C23 corrects that oversight.)

In my opinion, the main reason for NULL is that it lets the programmer
explicitly state that it's a null pointer constant and not just zero.
(But NULL can still be of type int.)  I find nullptr (in C++ and C23) an
improvement over NULL.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#120985

On 11/22/24 15:36, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
...
> `(void*)0` is a null pointer constant in C but not in C++, because C++
> has no implicit conversion from void* to other pointer types.
> 
> 0 is a null pointer constant, and a valid expansion for NULL, in both C
> and C++.
> 
> Note that `(void*)0` is a C null pointer constant, but not a valid
> expansion for NULL.  It needs to be `((void*)0)`.  (A painfully literal
> reading of the C standard up to and including C17 suggests that a
> parenthesized null pointer constant is not a null pointer constant, but
> C23 corrects that oversight.)
> 
> In my opinion, the main reason for NULL is that it lets the programmer
> explicitly state that it's a null pointer constant and not just zero.
> (But NULL can still be of type int.)  I find nullptr (in C++ and C23) an
> improvement over NULL.

I started writing that response thinking that this thread was on
comp.lang.c. Then I noticed this was comp.lang.c++, and made a few
corrections, but not as many as I should have.
I strongly agree - nullptr in C++ is what NULL should always have been,
but it took a couple of decade's experi9ence with C and C++ to figure
out the right way to do it.

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

#121000

On Fri, 2024-11-22 at 12:36 -0800, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> > On 11/21/24 08:43, Scott Lurndal wrote:
> > > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> > > > On 11/20/2024 2:33 PM, Chris M. Thomasson wrote:
> > > > > On 11/20/2024 2:11 PM, Scott Lurndal wrote:
> > > 
> > > > 
> > > > Actually, for some reason, this makes me think of nullptr = 0 = NULL wrt 
> > > > NULL can be 0xdeadbeefbeefdead?
> > > > 
> > > 
> > > I've worked with systems where the NULL pointer value was not zero.
> > > 
> > > That's why C has a symbolic constant for NULL.
> > 
> > Not really - that's the reason why C has special handling for null
> > pointer constants. Even on systems where null pointers are represented
> > by a bit pattern with one or more bits set, a null pointer constant can
> > still be 0, and if used in a pointer context, must be converted to a
> > null pointer. The main reason for NULL is that some implementations
> > thought it would be better for type safety to use (void*)0.
> 
> `(void*)0` is a null pointer constant in C but not in C++, because C++
> has no implicit conversion from void* to other pointer types.
> 
> 0 is a null pointer constant, and a valid expansion for NULL, in both C
> and C++.
> 
> Note that `(void*)0` is a C null pointer constant, but not a valid
> expansion for NULL.  It needs to be `((void*)0)`.  (A painfully literal
> reading of the C standard up to and including C17 suggests that a
> parenthesized null pointer constant is not a null pointer constant, but
> C23 corrects that oversight.)
> 
> In my opinion, the main reason for NULL is that it lets the programmer
> explicitly state that it's a null pointer constant and not just zero.
> (But NULL can still be of type int.)  I find nullptr (in C++ and C23) an
> improvement over NULL.
> 

IMO,from programmer's view:
NULL -> a pointer value that the dereference will cause UB.
      Whether it is a macro is irrelevant (so the expansion).
nullptr -> C++ wrapper of NULL (whatever the reason)
      assert(nullptr==NULL);
0  -> I think the language will take special care of it, if it converted
      to pointer value.

---------------------------------------------------
Linux man-pages 6.05              2023-02-05                      NULL(3const)

NAME
       NULL - null pointer constant

LIBRARY
       Standard C library (libc)

SYNOPSIS
       #include <stddef.h>

       #define NULL  ((void *) 0)

DESCRIPTION
       NULL  represents  a null pointer constant, that is, a pointer that does
       not point to anything.

CONFORMING TO
       C99 and later; POSIX.1-2001 and later.

.... [cut]
--------------------

Example:
  if(p==NULL) {/* ... */}
  if(p!=NULL) {/*.... */)

Note: Expression like "if(p)" or "if(!p)" explicitly adopts implicit conversion rule, unless it is
intended.

Of course, C++ language can do whatever it wants, but causing practical problems
and might be considered a bug.

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

#121018

wij <wyniijj5@gmail.com> writes:
[...]
> IMO,from programmer's view:
> NULL -> a pointer value that the dereference will cause UB.
>       Whether it is a macro is irrelevant (so the expansion).
> nullptr -> C++ wrapper of NULL (whatever the reason)
>       assert(nullptr==NULL);

nullptr exists in C++ (I don't remember when it was introduced) and in C
starting with C23.  It is, in my opinion, what should have been provided
in both languages instead of the NULL macro.

> 0  -> I think the language will take special care of it, if it converted
>       to pointer value.

Yes, 0 converted to a pointer type is guaranteed to yield a null pointer
value.  There are contexts where a pointer expression is required but 0
will not be implicitly converted to the expected type.  I'm thinking
specifically of arguments to variadic functions, but there may be
others.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#121021

On Mon, 2024-11-25 at 14:03 -0800, Keith Thompson wrote:
> wij <wyniijj5@gmail.com> writes:
> [...]
> > IMO,from programmer's view:
> > NULL -> a pointer value that the dereference will cause UB.
> >       Whether it is a macro is irrelevant (so the expansion).
> > nullptr -> C++ wrapper of NULL (whatever the reason)
> >       assert(nullptr==NULL);
> 
> nullptr exists in C++ (I don't remember when it was introduced) and in C
> starting with C23. 

Thanks, I didn't know that

>  It is, in my opinion, what should have been provided
> in both languages instead of the NULL macro.
> 
My question would be: why not make NULL a 'reserved' word, instead of macro?

> > 0  -> I think the language will take special care of it, if it converted
> >       to pointer value.
> 
> Yes, 0 converted to a pointer type is guaranteed to yield a null pointer
> value.  There are contexts where a pointer expression is required but 0
> will not be implicitly converted to the expected type.  I'm thinking
> specifically of arguments to variadic functions, but there may be
> others.
> 
So far, I can still avoid using variadic functions. I use overload. Implement
looks bad, but it works fine. Any way, inventing nullptr for such rare? case
is IOM overkill.

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

#121029

On Tue, 2024-11-26 at 12:21 +0800, wij wrote:
> On Mon, 2024-11-25 at 14:03 -0800, Keith Thompson wrote:
> > wij <wyniijj5@gmail.com> writes:
> > [...]
> > > IMO,from programmer's view:
> > > NULL -> a pointer value that the dereference will cause UB.
> > >       Whether it is a macro is irrelevant (so the expansion).
> > > nullptr -> C++ wrapper of NULL (whatever the reason)
> > >       assert(nullptr==NULL);
> > 
> > nullptr exists in C++ (I don't remember when it was introduced) and in C
> > starting with C23. 
> 
> Thanks, I didn't know that
> 
> >  It is, in my opinion, what should have been provided
> > in both languages instead of the NULL macro.
> > 
> My question would be: why not make NULL a 'reserved' word, instead of macro?
> 
> > > 0  -> I think the language will take special care of it, if it converted
> > >       to pointer value.
> > 
> > Yes, 0 converted to a pointer type is guaranteed to yield a null pointer
> > value.  There are contexts where a pointer expression is required but 0
> > will not be implicitly converted to the expected type.  I'm thinking
> > specifically of arguments to variadic functions, but there may be
> > others.
> > 
> So far, I can still avoid using variadic functions. I use overload. Implement
> looks bad, but it works fine. Any way, inventing nullptr for such rare? case
> is IOM overkill.

I think now, inventing nullptr is a practical step of evolution. So, in the
future, expansion of NULL might be nullptr. ... NULL will still be valid for 
a long time, both in C and C++.

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

#121030

On Wed, 27 Nov 2024 16:23:55 +0800
wij <wyniijj5@gmail.com> boring babbled:
>On Tue, 2024-11-26 at 12:21 +0800, wij wrote:
>> looks bad, but it works fine. Any way, inventing nullptr for such rare? c=
>ase
>> is IOM overkill.
>
>I think now, inventing nullptr is a practical step of evolution. So, in the
>future, expansion of NULL might be nullptr. ... NULL will still be valid fo=
>r=C2=A0
>a long time, both in C and C++.

Stop replying to your own nonsense with yet more nonsense. No one cares.

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

#121031

On Wed, 2024-11-27 at 08:26 +0000, Muttley@DastartdlyHQ.org wrote:
> On Wed, 27 Nov 2024 16:23:55 +0800
> wij <wyniijj5@gmail.com> boring babbled:
> > On Tue, 2024-11-26 at 12:21 +0800, wij wrote:
> > > looks bad, but it works fine. Any way, inventing nullptr for such rare? c=
> > ase
> > > is IOM overkill.
> > 
> > I think now, inventing nullptr is a practical step of evolution. So, in the
> > future, expansion of NULL might be nullptr. ... NULL will still be valid fo=
> > r=C2=A0
> > a long time, both in C and C++.
> 
> Stop replying to your own nonsense with yet more nonsense. No one cares.

It was a correction of my previous post. Not every post is for you.
If you feel sth have to utter, utter sth on topic. We know you are not there, but
we won't laught.

A clue for you: What should be in a 'portabe' program if ::fopen(..) failed? NULL 
or nullptr? What about "if(::fopen(..)"?

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

#121033

On 27.11.2024 12:48, wij wrote:
> 
> A clue for you: What should be in a 'portabe' program if ::fopen(..) failed? NULL
> or nullptr? What about "if(::fopen(..)"?

In a portable program one cannot just use fopen() as it does not work 
reliably with Unicode characters in Windows paths. One needs to use some 
kind of helper library for having portable code. In principle 
std::filesystem::path ought to work, but I have no experience with it.

About null pointers: in C++ it is spelled `nullptr`.

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

#121035

On Wed, 27 Nov 2024 15:39:51 +0200
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>On 27.11.2024 12:48, wij wrote:
>> 
>> A clue for you: What should be in a 'portabe' program if ::fopen(..) failed?
>NULL
>> or nullptr? What about "if(::fopen(..)"?
>
>In a portable program one cannot just use fopen() as it does not work 
>reliably with Unicode characters in Windows paths. One needs to use some 
>kind of helper library for having portable code. In principle 
>std::filesystem::path ought to work, but I have no experience with it.

So how does file access work in plain C in Windows then? I'm pretty sure
fopen() works fine given its a core C API function.

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

#121036

On Wed, 27 Nov 2024 13:54:04 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

> On Wed, 27 Nov 2024 15:39:51 +0200
> Paavo Helde <eesnimi@osa.pri.ee> wibbled:
> >On 27.11.2024 12:48, wij wrote:  
> >> 
> >> A clue for you: What should be in a 'portabe' program if
> >> ::fopen(..) failed?  
> >NULL  
> >> or nullptr? What about "if(::fopen(..)"?  
> >
> >In a portable program one cannot just use fopen() as it does not
> >work reliably with Unicode characters in Windows paths. One needs to
> >use some kind of helper library for having portable code. In
> >principle std::filesystem::path ought to work, but I have no
> >experience with it.  
> 
> So how does file access work in plain C in Windows then? I'm pretty
> sure fopen() works fine given its a core C API function.
> 

It works, but badly rather than fine.
Specifically, it works only with ASCII paths. Which, on Windows, happen
to be 2nd class. The biggest problem with ASCII paths on Windows is
that they are limited to 256 characters. Or to 512 characters if you
turn on some obscure registry keys. In practice, 256 characters quite
often is too short. 

Even big SW vendors sometimes fall in this trap. One example I
encountered recently is Xilinx (now owned by AMD).

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

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

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

csiph-web