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

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

question about nullptr

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

Contents

  question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-06 08:49 -0300
    Re: question about nullptr Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-06 14:13 +0200
    Re: question about nullptr John McCue <jmccue@neutron.jmcunx.com> - 2024-07-06 12:33 +0000
    Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-06 12:54 +0000
      Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 15:07 +0200
        Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 14:04 +0000
          Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 16:42 +0200
            Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 16:45 +0200
          Re: question about nullptr Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-06 10:50 -0700
            Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:04 +0000
              Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:06 -0700
          Re: question about nullptr bart <bc@freeuk.com> - 2024-07-06 19:20 +0100
            Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:09 +0000
            Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 16:31 -0700
          Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-06 13:23 -0700
            Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-06 13:28 -0700
              Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 08:01 +0000
                Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 22:08 -0700
            Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-07-06 17:04 -0400
              Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:10 +0000
            Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:03 +0000
            Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 21:44 -0400
              Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 19:29 -0700
                Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-07 12:53 -0700
            Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 08:03 +0000
          Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-06 23:14 +0100
            Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:13 +0000
              Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:10 -0700
              Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-07 08:46 +0000
              Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-07 19:59 +0100
                Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-07 19:40 +0000
                  Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-07 15:17 -0700
                    Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 20:11 +0200
                    Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-08 13:32 -0700
                    Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-08 22:28 +0300
                      Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 15:23 -0700
                        Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-09 10:48 +0300
                          Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 04:32 -0700
                            Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-09 09:10 -0300
                              Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 07:52 -0700
                                Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-09 13:16 -0300
                                  Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 14:22 -0700
                              Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 22:25 +0000
                                Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-10 08:50 -0300
                            Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-09 15:50 +0300
                              Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 07:50 -0700
                              Re: question about nullptr David Brown <david.brown@hesbynett.no> - 2024-07-09 18:19 +0200
                      Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 02:49 +0000
                        Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-09 11:00 +0300
                          Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 08:21 +0000
                          Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 03:57 -0700
                      Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-08 20:17 -0700
                        Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-08 21:01 -0700
                          Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 22:06 -0700
                          Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-10 07:51 -0700
                            Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 14:23 -0700
                              Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 18:50 -0400
                                Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 17:42 -0700
                                  Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-12 18:33 -0700
                              Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 18:10 -0700
                                Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-12 18:44 -0700
                    Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-08 14:09 +0000
                    Re: question about nullptr Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-08 21:45 -0700
                      Re: question about nullptr Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-08 21:49 -0700
                        Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-11 02:42 +0000
                      Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-08 22:58 -0700
                        Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-10 07:36 -0700
                          Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 14:15 -0700
                            Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 20:52 -0700
                  Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 20:07 +0200
                    Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 23:55 +0100
                      Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-10 17:28 +0200
                        Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 00:25 +0100
                          Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 14:08 +0200
                            Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-13 00:59 +0100
                              Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 04:01 +0200
                                Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-15 00:00 +0100
                            Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 04:18 +0200
                            Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-17 09:26 -0700
                  Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 12:29 +0200
                    Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 17:23 +0100
                  Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-08 11:03 -0400
                    Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 02:45 +0000
                  Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 11:08 +0200
                    Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 11:18 +0100
                      Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 02:32 +0000
                        Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 22:02 -0700
                        Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-09 10:21 +0100
                          Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-10 17:32 -0700
                            Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 02:12 +0100
                              Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-10 18:41 -0700
                    Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-11 02:38 +0000
                      Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 14:11 +0200
                  Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-07-08 07:18 -0400
                  Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-08 07:19 +0000
                  Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 00:42 +0100
            Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:36 -0700
        Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-06 22:11 +0000
      Re: question about nullptr bart <bc@freeuk.com> - 2024-07-06 14:51 +0100
        Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 04:55 +0000
          Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-07 00:04 -0700
          Re: question about nullptr bart <bc@freeuk.com> - 2024-07-07 18:40 +0100
      Re: question about nullptr Richard Harnden <richard.nospam@gmail.invalid> - 2024-07-12 14:19 +0100
        Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-12 21:52 +0000
          Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-12 22:27 +0000
            Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-12 23:28 +0000
              Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-13 00:10 +0000
                Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-12 20:28 -0400
                Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 17:30 -0700
        Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-13 17:21 -0700
        Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-15 22:51 +0000
          Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-15 16:32 -0700
          Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-15 19:49 -0400
            Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-15 18:22 -0700
            Re: question about nullptr dave_thompson_2@comcast.net - 2024-08-25 16:55 -0400
              Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-08-25 17:09 -0400
              Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 23:46 -0400
    Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-07-06 10:39 -0400
      Re: question about nullptr David Brown <david.brown@hesbynett.no> - 2024-07-06 18:57 +0200
        Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 08:00 +0000
          Re: question about nullptr David Brown <david.brown@hesbynett.no> - 2024-07-07 12:07 +0200
        Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-07 08:40 -0300
        Re: question about nullptr Richard Harnden <richard.nospam@gmail.invalid> - 2024-07-09 06:42 +0100
          Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 23:17 -0700
            Re: question about nullptr Richard Harnden <richard.nospam@gmail.invalid> - 2024-07-09 08:02 +0100
              Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-09 00:12 -0700
                Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-09 11:14 +0100
                  Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-09 13:24 -0700
                    Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-09 13:28 -0700
                      Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 14:27 +0100
                      Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 11:09 -0400
                        Re: question about nullptr dave_thompson_2@comcast.net - 2024-08-25 16:56 -0400
                          Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 20:48 -0400
                            Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-25 18:18 -0700
                              Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 23:45 -0400

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

#386945

On 09/07/2024 11:52, Tim Rentsch wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> 
>> On 09/07/2024 08:32, Tim Rentsch wrote:
>>
>>> Any use of '\0' almost always strikes me as an affectation.  It's
>>> like people want to somehow pretend that it's not the same as
>>> just 0.
>>
>> I like to pretend
>>
>> '\0'   is not int
>> 2 > 1  is not int
>> etc
>>
>> I know it is int, but I think this needs a redesign in C.
> 
> I strongly encourage you not to do that.  Based on past
> experience most of your ideas for improvements make
> things worse rather than better.

It is only for static analysis.

For instance:


enum  E {Z = 0};

int main()
{
   int * p;
   p = '\0';
   p = false;
   p = Z;
}

clang has 3 warnings for this code.

https://godbolt.org/z/56fn5PT4h

Especially for p = Z and p = '\0' we have value 0 of type int, but the 
compiler is not blind for the other characteristics.

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

#386961

Thiago Adams <thiago.adams@gmail.com> writes:

> On 09/07/2024 11:52, Tim Rentsch wrote:
>
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>
>>> On 09/07/2024 08:32, Tim Rentsch wrote:
>>>
>>>> Any use of '\0' almost always strikes me as an affectation.  It's
>>>> like people want to somehow pretend that it's not the same as
>>>> just 0.
>>>
>>> I like to pretend
>>>
>>> '\0'   is not int
>>> 2 > 1  is not int
>>> etc
>>>
>>> I know it is int, but I think this needs a redesign in C.
>>
>> I strongly encourage you not to do that.  Based on past
>> experience most of your ideas for improvements make
>> things worse rather than better.
>
> It is only for static analysis.
>
> For instance:
>
>
> enum  E {Z = 0};
>
> int main()
> {
>   int * p;
>   p = '\0';
>   p = false;
>   p = Z;
> }
>
> clang has 3 warnings for this code.
>
> https://godbolt.org/z/56fn5PT4h
>
> Especially for p = Z and p = '\0' we have value 0 of type int, but the
> compiler is not blind for the other characteristics.

You could give a master class in missing the point.

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

#386964

On 2024-07-09, Thiago Adams <thiago.adams@gmail.com> wrote:
> On 09/07/2024 08:32, Tim Rentsch wrote:
>> Any use of '\0' almost always strikes me as an affectation.  It's
>> like people want to somehow pretend that it's not the same as
>> just 0.
>
> I like to pretend
>
> '\0'   is not int

In C++ it isn't.

  void foo(int);
  void foo(char);

  foo(0);       // takes int overload
  foo('\0');    // takes char overload

> I don't like to think '\0' is null pointer.

I don't like that 1 - 1 is a null pointer. It's not a good design.

Nobody other than C humorists needs any zero-valued integer expression
whatsoever to be a null pointer constant.

How it should work is that only the token 0 is a null pointer constant.
Not 0L (ideally, not even 00 or 0x0, only the decimal token).

All zero-valued constant expressions of integer type should not be
null pointer constants, but ordinary expressions whch require
a cast to be converted to pointer type, and denote an address
associated with zero that may be different from the null pointer.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#386990

On 09/07/2024 19:25, Kaz Kylheku wrote:
> On 2024-07-09, Thiago Adams <thiago.adams@gmail.com> wrote:
>> On 09/07/2024 08:32, Tim Rentsch wrote:
>>> Any use of '\0' almost always strikes me as an affectation.  It's
>>> like people want to somehow pretend that it's not the same as
>>> just 0.
>>
>> I like to pretend
>>
>> '\0'   is not int
> 
> In C++ it isn't.
Yes

Yes there are several differences in C++.

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

#386935

On Tue, 09 Jul 2024 04:32:50 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> > On Mon, 8 Jul 2024 15:23:47 -0700
> > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
> >  
> >> On 7/8/2024 12:28 PM, Michael S wrote:
> >>  
> >>> On Sun, 07 Jul 2024 15:17:34 -0700
> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >>>  
> >>>> I just about always use NULL, not 0, when I want a null pointer
> >>>> constant.  Similarly, I use '\0', not 0, when I want a null
> >>>> character, 0.0 when I want a floating-point zero, and false when
> >>>> I want a Boolean zero.  I just like being explicit.  
> >>>
> >>> Pointer:  I very rarely use NULL.
> >>> Character:  I never use '\0'.  
> >>
> >> Not even something like:
> >>
> >> #define CLINE 128
> >>
> >> char x[CLINE] = { '\0' };
> >>
> >> ?
> >>
> >> ;^)  
> >
> > I see nothing special about your case. {0} is the most appropriate.
> >  
> 
> Any use of '\0' almost always strikes me as an affectation.  It's
> like people want to somehow pretend that it's not the same as
> just 0.
> 
> > And, BTW, I never use #define for integer constants.  
> 
> What do you do if you need to define a compile-time constant
> whose value is outside the range of signed int?  With the
> understanding that the context is C as it is now, and not
> C++ or some imagined other language.

In comment above "integer constant" meant "within the range of signed
int". But let's accept more general meaning. Then, when it happens, I
have a problem and forced to flex my principles :(
Luckily, it's pretty rare. I mean, it's pretty rare that the constant
is both outside the range of signed int and I really really have to
have it as compile-time constant. More often big numbers like these are
used in arithmetic/logic, so 'const wide_type' or 'static const
wide_type' is practically as good as a "real" compile-time constant
despite being "less constant" in theory.

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

#386938

Michael S <already5chosen@yahoo.com> writes:

> On Tue, 09 Jul 2024 04:32:50 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Mon, 8 Jul 2024 15:23:47 -0700
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>>>
>>>> On 7/8/2024 12:28 PM, Michael S wrote:
>>>>
>>>>> On Sun, 07 Jul 2024 15:17:34 -0700
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>
>>>>>> I just about always use NULL, not 0, when I want a null pointer
>>>>>> constant.  Similarly, I use '\0', not 0, when I want a null
>>>>>> character, 0.0 when I want a floating-point zero, and false when
>>>>>> I want a Boolean zero.  I just like being explicit.
>>>>>
>>>>> Pointer:  I very rarely use NULL.
>>>>> Character:  I never use '\0'.
>>>>
>>>> Not even something like:
>>>>
>>>> #define CLINE 128
>>>>
>>>> char x[CLINE] = { '\0' };
>>>>
>>>> ?
>>>>
>>>> ;^)
>>>
>>> I see nothing special about your case. {0} is the most appropriate.
>>
>> Any use of '\0' almost always strikes me as an affectation.  It's
>> like people want to somehow pretend that it's not the same as
>> just 0.
>>
>>> And, BTW, I never use #define for integer constants.
>>
>> What do you do if you need to define a compile-time constant
>> whose value is outside the range of signed int?  With the
>> understanding that the context is C as it is now, and not
>> C++ or some imagined other language.
>
> In comment above "integer constant" meant "within the range of signed
> int".  But let's accept more general meaning.  Then, when it happens, I
> have a problem and forced to flex my principles :(
> Luckily, it's pretty rare.  I mean, it's pretty rare that the constant
> is both outside the range of signed int and I really really have to
> have it as compile-time constant.

I agree it's not common.  I was just wondering what you would
do if it came up (and as it happens it did come up for me
recently, and I used a #define rather than trying to find an
alternative).

> More often big numbers like these are
> used in arithmetic/logic, so 'const wide_type' or 'static const
> wide_type' is practically as good as a "real" compile-time constant
> despite being "less constant" in theory.

I routinely use initialized ordinary variables rather than
other methods, when the variables work.  Incidentally, IME
the results are better with automatic variables rather than
static.  For arrays or structs, static might be better, but
for simple scalar values I normally use ordinary automatics
rather than statics.

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

#386946

On 09/07/2024 14:50, Michael S wrote:
> On Tue, 09 Jul 2024 04:32:50 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> 
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Mon, 8 Jul 2024 15:23:47 -0700
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>>>   
>>>> On 7/8/2024 12:28 PM, Michael S wrote:
>>>>   
>>>>> On Sun, 07 Jul 2024 15:17:34 -0700
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>   
>>>>>> I just about always use NULL, not 0, when I want a null pointer
>>>>>> constant.  Similarly, I use '\0', not 0, when I want a null
>>>>>> character, 0.0 when I want a floating-point zero, and false when
>>>>>> I want a Boolean zero.  I just like being explicit.
>>>>>
>>>>> Pointer:  I very rarely use NULL.
>>>>> Character:  I never use '\0'.
>>>>
>>>> Not even something like:
>>>>
>>>> #define CLINE 128
>>>>
>>>> char x[CLINE] = { '\0' };
>>>>
>>>> ?
>>>>
>>>> ;^)
>>>
>>> I see nothing special about your case. {0} is the most appropriate.
>>>   
>>
>> Any use of '\0' almost always strikes me as an affectation.  It's
>> like people want to somehow pretend that it's not the same as
>> just 0.
>>
>>> And, BTW, I never use #define for integer constants.
>>
>> What do you do if you need to define a compile-time constant
>> whose value is outside the range of signed int?  With the
>> understanding that the context is C as it is now, and not
>> C++ or some imagined other language.
> 
> In comment above "integer constant" meant "within the range of signed
> int". But let's accept more general meaning. Then, when it happens, I
> have a problem and forced to flex my principles :(
> Luckily, it's pretty rare. I mean, it's pretty rare that the constant
> is both outside the range of signed int and I really really have to
> have it as compile-time constant. More often big numbers like these are
> used in arithmetic/logic, so 'const wide_type' or 'static const
> wide_type' is practically as good as a "real" compile-time constant
> despite being "less constant" in theory.
> 

static const of the appropriate type should be as good as a define'd 
value in almost any circumstance (assuming, of course, an optimising 
compiler).

There are circumstances where you can use an enumeration constant as a 
named integer constant, but where a static const int value cannot be 
used, such as the size of statically allocated arrays.  But you are very 
unlikely to need such a large value to be an integer constant, rather 
than just a value that the compiler sees as a compile-time constant for 
optimisation purposes.

(And C23 helpfully allows enum values that are of larger integer types. 
And also "constexpr" declarations.)

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

#386906

On 2024-07-08, Michael S <already5chosen@yahoo.com> wrote:
> On Sun, 07 Jul 2024 15:17:34 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> 
>> I just about always use NULL, not 0, when I want a null pointer
>> constant.  Similarly, I use '\0', not 0, when I want a null character,
>> 0.0 when I want a floating-point zero, and false when I want a Boolean
>> zero.  I just like being explicit.
>> 
>
> Pointer: I very rarely use NULL.
> Character: I never use '\0'.
> Floating point: I never use 0.0.

Never say never!

  printf("%f\n", 0);   // undefined behavior.
  printf("%f\n", 0.0); // correct

If you're #define-ing a floating-point constant that has
no fractional part, you should put that .0 there.

Someone's going to pass your constant as a variadic argument,
where it doesn't convert to floating-point.

Also:

  1/3   -> 0
  1/3.0 -> 0.33333...

If you're #define-ing a floating point constant that has
no fractional part, and don't include the .0, and the
programmer uses it as a division denominator thinking that
it's a floating-point quantity, oops!

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#386923

On Tue, 9 Jul 2024 02:49:49 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

> On 2024-07-08, Michael S <already5chosen@yahoo.com> wrote:
> > On Sun, 07 Jul 2024 15:17:34 -0700
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >  
> >> 
> >> I just about always use NULL, not 0, when I want a null pointer
> >> constant.  Similarly, I use '\0', not 0, when I want a null
> >> character, 0.0 when I want a floating-point zero, and false when I
> >> want a Boolean zero.  I just like being explicit.
> >>   
> >
> > Pointer: I very rarely use NULL.
> > Character: I never use '\0'.
> > Floating point: I never use 0.0.  
> 
> Never say never!
> 
>   printf("%f\n", 0);   // undefined behavior.
>   printf("%f\n", 0.0); // correct
>

Yes, but that's extremely rare that I want constant (except string
literal) as variable argument to printf().

> If you're #define-ing a floating-point constant that has
> no fractional part, you should put that .0 there.
>

I am trying hard to avoid #define-ing floating-point constants.
In rare cases where it is not avoidable, most often the constant does
have fractional part. I am not sure what I would prefer when I can't
avoid #define-ing and the constant has no fractional part. Will I write
something like '#define ANSWER ((double)42)' or (42.0) ?
It depends on the mood of the minute.

> Someone's going to pass your constant as a variadic argument,
> where it doesn't convert to floating-point.
> 
> Also:
> 
>   1/3   -> 0
>   1/3.0 -> 0.33333...
> 
> If you're #define-ing a floating point constant that has
> no fractional part, and don't include the .0, and the
> programmer uses it as a division denominator thinking that
> it's a floating-point quantity, oops!
> 

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

#386924

On 2024-07-09, Michael S <already5chosen@yahoo.com> wrote:
> On Tue, 9 Jul 2024 02:49:49 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>
>> On 2024-07-08, Michael S <already5chosen@yahoo.com> wrote:
>> > On Sun, 07 Jul 2024 15:17:34 -0700
>> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> >  
>> >> 
>> >> I just about always use NULL, not 0, when I want a null pointer
>> >> constant.  Similarly, I use '\0', not 0, when I want a null
>> >> character, 0.0 when I want a floating-point zero, and false when I
>> >> want a Boolean zero.  I just like being explicit.
>> >>   
>> >
>> > Pointer: I very rarely use NULL.
>> > Character: I never use '\0'.
>> > Floating point: I never use 0.0.  
>> 
>> Never say never!
>> 
>>   printf("%f\n", 0);   // undefined behavior.
>>   printf("%f\n", 0.0); // correct
>>
>
> Yes, but that's extremely rare that I want constant (except string
> literal) as variable argument to printf().

Under the paradigm of "I write code only for myself", almost
anything is justifiable.

The "I want" stuff goes out the window as soon as your source code is
consumed by other programmers.  (Interfaced with, patched, taken
over by ...). Anything you define could be used in ways you wouldn't
do yourself.


  // #define GRAV 9.81
  #define GRAV 3

  ...

     printf("configured with\n");
     ...
     printf("GRAV=%g\n", GRAV);


>> If you're #define-ing a floating-point constant that has
>> no fractional part, you should put that .0 there.
>>
>
> I am trying hard to avoid #define-ing floating-point constants.
> In rare cases where it is not avoidable, most often the constant does
> have fractional part. I am not sure what I would prefer when I can't
> avoid #define-ing and the constant has no fractional part. Will I write
> something like '#define ANSWER ((double)42)' or (42.0) ?
> It depends on the mood of the minute.

You don't need parentheses around 42.0, because the floating point
dot has a higher precedence than any operator. :-)

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#386931

Michael S <already5chosen@yahoo.com> writes:

> On Tue, 9 Jul 2024 02:49:49 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>
>> On 2024-07-08, Michael S <already5chosen@yahoo.com> wrote:
>>
>>> On Sun, 07 Jul 2024 15:17:34 -0700
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>
>>>> I just about always use NULL, not 0, when I want a null pointer
>>>> constant.  Similarly, I use '\0', not 0, when I want a null
>>>> character, 0.0 when I want a floating-point zero, and false when I
>>>> want a Boolean zero.  I just like being explicit.
>>>
>>> Pointer:  I very rarely use NULL.
>>> Character:  I never use '\0'.
>>> Floating point:  I never use 0.0.
>>
>> Never say never!
>>
>>   printf("%f\n", 0);   // undefined behavior.
>>   printf("%f\n", 0.0); // correct
>
> Yes, but that's extremely rare that I want constant (except string
> literal) as variable argument to printf().
>
>> If you're #define-ing a floating-point constant that has
>> no fractional part, you should put that .0 there.
>
> I am trying hard to avoid #define-ing floating-point constants.
> In rare cases where it is not avoidable, most often the constant does
> have fractional part.  I am not sure what I would prefer when I can't
> avoid #define-ing and the constant has no fractional part.  Will I write
> something like '#define ANSWER ((double)42)' or (42.0) ?
> It depends on the mood of the minute.

Normally I would leave off the final 0 and just write 42.

Alternatively, a floating-point 42 can be written 42e0,
which stands out a little more than just using a trailing
dot.

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

#386907

Michael S <already5chosen@yahoo.com> writes:

> On Sun, 07 Jul 2024 15:17:34 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> I just about always use NULL, not 0, when I want a null pointer
>> constant.  Similarly, I use '\0', not 0, when I want a null character,
>> 0.0 when I want a floating-point zero, and false when I want a Boolean
>> zero.  I just like being explicit.
>
> Pointer:  I very rarely use NULL.
> Character:  I never use '\0'.
> Floating point:  I never use 0.0.
> Boolean:  I use false much more often than 0.

This posting has inspired me to try using (long)0.0
whenever a null pointer constant is needed.  As for
example

    (void*){ (long)0.0 }

as an argument to a variadic function where a pointer
is expected.

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

#386908

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> This posting has inspired me to try using (long)0.0
> whenever a null pointer constant is needed.  As for
> example
>
>     (void*){ (long)0.0 }
>
> as an argument to a variadic function where a pointer
> is expected.

But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.

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

#386912

On 7/8/2024 9:01 PM, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>> This posting has inspired me to try using (long)0.0
>> whenever a null pointer constant is needed.  As for
>> example
>>
>>      (void*){ (long)0.0 }
>>
>> as an argument to a variadic function where a pointer
>> is expected.
> 
> But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
> 

Who is surely? lol!

https://youtu.be/ixljWVyPby0

;^)

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

#386998

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>
>> This posting has inspired me to try using (long)0.0
>> whenever a null pointer constant is needed.  As for
>> example
>>
>>     (void*){ (long)0.0 }
>>
>> as an argument to a variadic function where a pointer
>> is expected.
>
> But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.

Surely not.  Furthermore the form I showed has a point,
whereas this example is roughly the equivalent of a
first grade knock-knock joke.

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

#387019

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>> This posting has inspired me to try using (long)0.0
>>> whenever a null pointer constant is needed.  As for
>>> example
>>>
>>>     (void*){ (long)0.0 }
>>>
>>> as an argument to a variadic function where a pointer
>>> is expected.
>>
>> But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
>
> Surely not.  Furthermore the form I showed has a point,
> whereas this example is roughly the equivalent of a
> first grade knock-knock joke.

I was of course joking.  I assumed you were as well.

What is the point of (void*){ (long)0.0 }?  I don't believe it's a null
pointer constant even in C23.  My example is.

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

#387025

On 7/10/24 17:23, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [...]
>>>
>>>> This posting has inspired me to try using (long)0.0
>>>> whenever a null pointer constant is needed. As for
>>>> example
>>>>
>>>> (void*){ (long)0.0 }
>>>>
>>>> as an argument to a variadic function where a pointer
>>>> is expected.
>>>
>>> But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
>>
>> Surely not. Furthermore the form I showed has a point,
>> whereas this example is roughly the equivalent of a
>> first grade knock-knock joke.
>
> I was of course joking. I assumed you were as well.
>
> What is the point of (void*){ (long)0.0 }? I don't believe it's a null
> pointer constant even in C23.

I think you're right about that.

"An integer constant expression132) ... shall only have operands that
are ... compound literal constants of arithmetic type that are the
immediate operands of casts. ... Cast operators in an integer constant
expression shall only convert arithmetic types to integer types, ...",
so (long)0.0 is permitted."

While (void*) looks like a cast, in this context it is a compound
literal of pointer type, which is not allowed. If he had written

(void*)(long)0.0

that would not have been a problem.

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

#387533

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 7/10/24 17:23, Keith Thompson wrote:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> [...]
>>>>
>>>>> This posting has inspired me to try using (long)0.0
>>>>> whenever a null pointer constant is needed.  As for
>>>>> example
>>>>>
>>>>> (void*){ (long)0.0 }
>>>>>
>>>>> as an argument to a variadic function where a pointer
>>>>> is expected.
>>>>
>>>> But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
>>>
>>> Surely not.  Furthermore the form I showed has a point,
>>> whereas this example is roughly the equivalent of a
>>> first grade knock-knock joke.
>>
>> I was of course joking.  I assumed you were as well.
>>
>> What is the point of (void*){ (long)0.0 }?  I don't believe it's
>> a null pointer constant even in C23.
>
> I think you're right about that.

The compound literal is not a null pointer constant.  I didn't
say it is.  The null pointer constant is (long)0.0, like my
earlier posting pointed out.

> "An integer constant expression132) ... shall only have operands
> that are ... compound literal constants of arithmetic type that
> are the immediate operands of casts. ... Cast operators in an
> integer constant expression shall only convert arithmetic types to
> integer types, ...", so (long)0.0 is permitted."
>
> While (void*) looks like a cast, in this context it is a compound
> literal of pointer type, which is not allowed.  [..]

Don't be silly.  The compound literal works just fine in the
context I mentioned for it:

    #include <stdio.h>

    int
    main(){
        printf( " null pointer : %p\n", (void*){ (long)0.0 } );
        return  0;
    }

Compile it for yourself if you don't believe me.

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

#387535

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 7/10/24 17:23, Keith Thompson wrote:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>> [...]
>>>>>> This posting has inspired me to try using (long)0.0
>>>>>> whenever a null pointer constant is needed.  As for
>>>>>> example
>>>>>>
>>>>>> (void*){ (long)0.0 }
>>>>>>
>>>>>> as an argument to a variadic function where a pointer
>>>>>> is expected.
>>>>>
>>>>> But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
>>>>
>>>> Surely not.  Furthermore the form I showed has a point,
>>>> whereas this example is roughly the equivalent of a
>>>> first grade knock-knock joke.
>>>
>>> I was of course joking.  I assumed you were as well.
>>>
>>> What is the point of (void*){ (long)0.0 }?  I don't believe it's
>>> a null pointer constant even in C23.
>>
>> I think you're right about that.
>
> The compound literal is not a null pointer constant.  I didn't
> say it is.  The null pointer constant is (long)0.0, like my
> earlier posting pointed out.
>
>> "An integer constant expression132) ... shall only have operands
>> that are ... compound literal constants of arithmetic type that
>> are the immediate operands of casts. ... Cast operators in an
>> integer constant expression shall only convert arithmetic types to
>> integer types, ...", so (long)0.0 is permitted."
>>
>> While (void*) looks like a cast, in this context it is a compound
>> literal of pointer type, which is not allowed.  [..]
>
> Don't be silly.  The compound literal works just fine in the
> context I mentioned for it:
>
>     #include <stdio.h>
>
>     int
>     main(){
>         printf( " null pointer : %p\n", (void*){ (long)0.0 } );
>         return  0;
>     }
>
> Compile it for yourself if you don't believe me.

You're right, a null pointer constant is not required in that context.
`(long)0.0` is null pointer constant.  `(void*){ (long)0.0 }` is not a
null pointer constant, but it is an expression whose value is a null
pointer of type void*.  (It is, for example, not valid as an initializer
for a pointer object with static storage duration.)

The question you're refusing to answer is: *what is the point*?  Why
would you want to use `(void*){ (long)0.0 }` in a context where a null
pointer is required, rather than the much clearer `(void*)NULL`, or
`(void*)0`, or any of several other possible expressions?

Yes, it's valid and is guaranteed to work properly, but why?

Again, my reference to `((void*)('/'/'/'-'/'/'/'))` was nothing more or
less than a joke.  It is a valid null pointer constant, written for the
sole purpose of deliberate obfuscation.  I found it amusing.  If you
don't, that's fine.  It is not something I would write in real code
unless my goal were either obfuscation, testing a compiler's handling of
odd code, or just demonstrating the range of weird expressions that can
be null pointer constants.

I initially assumed that you had written `(void*){ (long)0.0 }` with a
similar intent.  I'm still not sure you didn't.

I cannot force you to explain, and if you choose not to do so I will
simply cease caring about this.  But I continue to be annoyed by your
habit of telling us that something obscure has some significance and
refusing to explain, even when asked, what that sigificance is.

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

#387534

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [...]
>>>
>>>> This posting has inspired me to try using (long)0.0
>>>> whenever a null pointer constant is needed.  As for
>>>> example
>>>>
>>>>     (void*){ (long)0.0 }
>>>>
>>>> as an argument to a variadic function where a pointer
>>>> is expected.
>>>
>>> But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
>>
>> Surely not.  Furthermore the form I showed has a point,
>> whereas this example is roughly the equivalent of a
>> first grade knock-knock joke.
>
> I was of course joking.  I assumed you were as well.
>
> What is the point of (void*){ (long)0.0 }?  I don't believe it's a
> null pointer constant even in C23.

The null pointer constant is (long)0.0, which it must be for the
compound literal to work.  Besides making it obvious that (long)0.0
is a null pointer constant, the compound literal is safer than
using just a cast.

> My example is.

Your example actually has two null pointer constants:  the
expression being casted, and the full expression casting a null
pointer constant to (void*).  But in neither case is that especially
obvious.  Also the expression you wrote is less safe.  For example,
if it had been written ((void*)('/'/'/'+'/'/'/')), the result would
still be legal C, and compile without problem, but would very likely
not be what was desired.  By contrast, if the compound literal had
been written (void*){ (long)1.0 }, it simply would not give a clean
compile, indicating that something is likely askew.

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

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

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

csiph-web