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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#386854

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 6 Jul 2024 14:51:19 +0100, bart wrote:
>> Using actual zero for a pointer value is crass. This wouldn't work for
>> example:
>> 
>>     char *p = 3;
>
> But of course this does:
>
>     char *p = 0;
>
> From the C23 spec, I found this footnote in §6.6:
>
>     A named constant or compound literal constant of integer type and
>     value zero is a null pointer constant. A named constant or
>     compound literal constant with a pointer type and a value null is
>     a null pointer but not a null pointer constant; it may only be
>     used to initialize a pointer object if its type implicitly
>     converts to the target type.
>
> That first sentence is so important, you’d think it would be in the main 
> text somewhere.

The definition of "null pointer constant" is in N3220 6.3.2.3,
(Conversions, Other operands, Pointers):

    An integer constant expression with the value 0, such an expression
    cast to type void *, or the predefined constant nullptr is called a
    *null pointer constant*.

6.6 makes it clear that named constants and compound literal constants
of integer type are integer constant expressions.

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

#386863

On 07/07/2024 05:55, Lawrence D'Oliveiro wrote:
> On Sat, 6 Jul 2024 14:51:19 +0100, bart wrote:
> 
>> Using actual zero for a pointer value is crass. This wouldn't work for
>> example:
>>
>>      char *p = 3;
> 
> But of course this does:
> 
>      char *p = 0;
> 
>  From the C23 spec, I found this footnote in §6.6:
> 
>      A named constant or compound literal constant of integer type and
>      value zero is a null pointer constant. A named constant or
>      compound literal constant with a pointer type and a value null is
>      a null pointer but not a null pointer constant; it may only be
>      used to initialize a pointer object if its type implicitly
>      converts to the target type.
> 
> That first sentence is so important, you’d think it would be in the main
> text somewhere.

It doesn't tell the full story, as you can have any arbitrary expression 
of such terms that results in a suitable value:

      char* p = width*height;

This is valid if width/height are enums and that area calculation yields 
zero. But update values slightly and it no longer compiles.

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

#387095

On 06/07/2024 13:54, Kaz Kylheku wrote:
> On 2024-07-06, Thiago Adams <thiago.adams@gmail.com> wrote:
>> If you were creating C code today and could use a C23 compiler, would
>> you use nullptr instead of NULL?
> 
> In greenfield projects under my dictatorship, I use 0, as in:
> 
>     char *p = 0;
> 
> I was still 20 something when I (easily) wrapped my head around the 0
> null pointer constant, and have not had any problems with it.
> Once I learned the standard-defined truth about null pointer constants,
> and their relationship to the NULL macro, I dropped NULL like a hot
> potato, and didn't look back (except when working in code bases that use
> NULL).
> 

I don't understand why you wouldn't use NULL.

If it's a pointer: NULL
If it's an integer: 0
If it's a double: 0.0
If it's a char: '\0'

Don't you use '\n'? Surely nobody would say 0x0a?

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

#387113

On 2024-07-12, Richard Harnden <richard.nospam@gmail.invalid> wrote:
> On 06/07/2024 13:54, Kaz Kylheku wrote:
>> On 2024-07-06, Thiago Adams <thiago.adams@gmail.com> wrote:
>>> If you were creating C code today and could use a C23 compiler, would
>>> you use nullptr instead of NULL?
>> 
>> In greenfield projects under my dictatorship, I use 0, as in:
>> 
>>     char *p = 0;
>> 
>> I was still 20 something when I (easily) wrapped my head around the 0
>> null pointer constant, and have not had any problems with it.
>> Once I learned the standard-defined truth about null pointer constants,
>> and their relationship to the NULL macro, I dropped NULL like a hot
>> potato, and didn't look back (except when working in code bases that use
>> NULL).
>> 
>
> I don't understand why you wouldn't use NULL.
>
> If it's a pointer: NULL
> If it's an integer: 0
> If it's a double: 0.0
> If it's a char: '\0'
>
> Don't you use '\n'? Surely nobody would say 0x0a?

But, see, nobody in their right mind would say '\012` for that. '\0'
an octal escape sequence like '\012', not a role-based character
abstraction like '\n'.  There is no null character abstraction because
the null character is the concrete zero code.

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

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

#387114

Kaz Kylheku <643-408-1753@kylheku.com> writes:
>On 2024-07-12, Richard Harnden <richard.nospam@gmail.invalid> wrote:

>>
>> Don't you use '\n'? Surely nobody would say 0x0a?

>But, see, nobody in their right mind would say '\012` for that. '\0'
>an octal escape sequence like '\012', not a role-based character
>abstraction like '\n'.

Actually, it's entirely likely that a programmer using C in 1978
would have used \012 for newline - it was the custom to use octal
on the PDP-11.   Consider the od(1) utility, for example.

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

#387115

On 2024-07-12, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>On 2024-07-12, Richard Harnden <richard.nospam@gmail.invalid> wrote:
>
>>>
>>> Don't you use '\n'? Surely nobody would say 0x0a?
>
>>But, see, nobody in their right mind would say '\012` for that. '\0'
>>an octal escape sequence like '\012', not a role-based character
>>abstraction like '\n'.
>
> Actually, it's entirely likely that a programmer using C in 1978
> would have used \012 for newline - it was the custom to use octal
> on the PDP-11.   Consider the od(1) utility, for example.

But why would they use '\012', if 012 was available. The quotes
and backslash doubles the character count and create visual clutter.

If I want the number 10 of type int, why would I switch into
a character quote inside of which I have to escape back to
a numeric specification.

In C++ it makes sense, because we get the char type, which can
be important:  foo('\012') -> pick the foo(char) overload, not
the foo(int).

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

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

#387117

Kaz Kylheku <643-408-1753@kylheku.com> writes:
>On 2024-07-12, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>On 2024-07-12, Richard Harnden <richard.nospam@gmail.invalid> wrote:
>>
>>>>
>>>> Don't you use '\n'? Surely nobody would say 0x0a?
>>
>>>But, see, nobody in their right mind would say '\012` for that. '\0'
>>>an octal escape sequence like '\012', not a role-based character
>>>abstraction like '\n'.

Because '\012' is a character.   012 is an int.  Using the former
ensures that any overflow will be detected at compile time and make
it clear to any future reader that the author intended it to be a
character, not an integer.

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

#387118

On 7/12/24 20:10, Scott Lurndal wrote:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>> On 2024-07-12, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
...
>>>> But, see, nobody in their right mind would say '\012` for that. '\0'
>>>> an octal escape sequence like '\012', not a role-based character
>>>> abstraction like '\n'.
> 
> Because '\012' is a character.   012 is an int.  Using the former
> ensures that any overflow will be detected at compile time and


No, it does not. In C "An integer character constant has type int.".
(6.4.4.4p11), the same type as 012. A compiler could warn you about such
problems, but it's not required to, and a conforming compiler is not
allowed to reject code on that basis.

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

#387119

scott@slp53.sl.home (Scott Lurndal) writes:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>On 2024-07-12, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>>>On 2024-07-12, Richard Harnden <richard.nospam@gmail.invalid> wrote:
>>>>> Don't you use '\n'? Surely nobody would say 0x0a?
>>>
>>>>But, see, nobody in their right mind would say '\012` for that. '\0'
>>>>an octal escape sequence like '\012', not a role-based character
>>>>abstraction like '\n'.
>
> Because '\012' is a character.   012 is an int.  Using the former
> ensures that any overflow will be detected at compile time and make
> it clear to any future reader that the author intended it to be a
> character, not an integer.

'\012' is a character constant.  012 is an integer constant.  Both are
of type int, and both have the same value, 10.

It's true that an octal character constant with a value exceeding
UCHAR_MAX is a constraint violation (like '\400' if UCHAR_MAX is 255),
and if you provide more than 3 digits the result is a multi-character
constant, which is likely to trigger a warning.  But any overflow would
almost certainly be the result of a typo, and guarding against that
doesn't strike me as a good reason to use one kind of constant over
another.

Having said that, I absolutely do prefer to use character constants for
character data ('\012' or '\x0a' if I want a character with value 10, or
more likely '\n' if I want a newline).  But that's for the benefit of
the reader, not of the compiler.

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

#387143

Richard Harnden <richard.nospam@gmail.invalid> writes:

> On 06/07/2024 13:54, Kaz Kylheku wrote:
>
>> On 2024-07-06, Thiago Adams <thiago.adams@gmail.com> wrote:
>>
>>> If you were creating C code today and could use a C23 compiler, would
>>> you use nullptr instead of NULL?
>>
>> In greenfield projects under my dictatorship, I use 0, as in:
>>
>>     char *p = 0;
>>
>> I was still 20 something when I (easily) wrapped my head around the 0
>> null pointer constant, and have not had any problems with it.
>> Once I learned the standard-defined truth about null pointer constants,
>> and their relationship to the NULL macro, I dropped NULL like a hot
>> potato, and didn't look back (except when working in code bases that use
>> NULL).
>
> I don't understand why you wouldn't use NULL.

The arguments I have heard for using NULL sound a lot like
the reason given for climbing Mount Everest.  (Incidentally
the person who said that died trying to climb the mountain.)

> If it's a pointer:  NULL

In most cases I would use 0, converted to an appropriate
pointer type using a compound literal if necessary.

> If it's an integer: 0

Yes in almost all cases.

> If it's a double:  0.0

In most cases where an integral value is needed for a
floating-point type I would use an integer.  Sometimes
a judicious 0. or 1. is needed to force conversion.

> If it's a char: '\0'

The integer constant '\0' reminds me of the short poem
about a purple cow.

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

#387153

On Fri, 12 Jul 2024 14:19:19 +0100, Richard Harnden wrote:

> Don't you use '\n'? Surely nobody would say 0x0a?

Why not full symbolic Unicode names, à la Python:

    "\n" == "\N{LINE FEED}"

⇒

    True

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

#387154

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 12 Jul 2024 14:19:19 +0100, Richard Harnden wrote:
>> Don't you use '\n'? Surely nobody would say 0x0a?
>
> Why not full symbolic Unicode names, à la Python:
>
>     "\n" == "\N{LINE FEED}"
>
> ⇒
>
>     True

Because C doesn't have that feature and is not expected to any
time soon, because C doesn't specify that '\n' is line feed, and
because using something like "\N{LINE FEED}" to denote a simple
newline charater would be silly because '\n' is already standard
and universally recognized by all C programmers.

Why do you ask?  Seriously, why did you ask this?

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

#387156

On 7/15/24 18:51, Lawrence D'Oliveiro wrote:
> On Fri, 12 Jul 2024 14:19:19 +0100, Richard Harnden wrote:
> 
>> Don't you use '\n'? Surely nobody would say 0x0a?
> 
> Why not full symbolic Unicode names, à la Python:
> 
>     "\n" == "\N{LINE FEED}"
> 
> ⇒
> 
>     True

Keep in mind that, in text mode, the <stdio.h> library routines use '\n'
in memory to represent whatever platform-specific method is used in
files to indicate a new line. For example, that can be a simple '\n' on
typical Unix-like machines, '\n\r' or '\r\n' on other operating systems,
and on a number of older systems, it could be converted to and from a
fixed-size block with a character count at the the beginning of the
block. There's no requirement that it be the Unicode line feed character.

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

#387158

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 7/15/24 18:51, Lawrence D'Oliveiro wrote:
>> On Fri, 12 Jul 2024 14:19:19 +0100, Richard Harnden wrote:
>> 
>>> Don't you use '\n'? Surely nobody would say 0x0a?
>> 
>> Why not full symbolic Unicode names, à la Python:
>> 
>>     "\n" == "\N{LINE FEED}"
>> 
>> ⇒
>> 
>>     True
>
> Keep in mind that, in text mode, the <stdio.h> library routines use '\n'
> in memory to represent whatever platform-specific method is used in
> files to indicate a new line. For example, that can be a simple '\n' on
> typical Unix-like machines, '\n\r' or '\r\n' on other operating systems,
> and on a number of older systems, it could be converted to and from a
> fixed-size block with a character count at the the beginning of the
> block. There's no requirement that it be the Unicode line feed character.

To be clear (and I'm sure you know this), that conversion occurs on
input and output, not when a string literal is compiled.

Even if an OS uses a single byte as an end-of-line marker in disk files,
none of '\n', ASCII LF, and the external representation have to match
(though it's certainly convenient if they all do).  An implementation
could have '\n' represent ASCII LF in memory but use ASCII CR to mark
line endings in files.

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

#387774

On Mon, 15 Jul 2024 19:49:08 -0400, James Kuyper
<jameskuyper@alumni.caltech.edu> wrote:

> On 7/15/24 18:51, Lawrence D'Oliveiro wrote:
[silliness]
> Keep in mind that, in text mode, the <stdio.h> library routines use '\n'
> in memory to represent whatever platform-specific method is used in
> files to indicate a new line. For example, that can be a simple '\n' on
> typical Unix-like machines, '\n\r' or '\r\n' on other operating systems,
> and on a number of older systems, it could be converted to and from a
> fixed-size block with a character count at the the beginning of the
> block. There's no requirement that it be the Unicode line feed character.

I never knew any older system that used a fixed-size block (or rather
record, which in those days was not the same as block) AND prefix
count in the same file, although OS/360 et seq used ONE of them.

And Tandem Enscribe used either offset or count fields (depending on
structure) at _end_ of block, near but not adjacent to records, except
for textfiles had prefix counts per line AND word (of nonblanks) --
but the initial versions of their C implementation couldn't handle
textfiles, so you had to convert them to and from 'data'.

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

#387777

On 8/25/24 4:55 PM, dave_thompson_2@comcast.net wrote:
> On Mon, 15 Jul 2024 19:49:08 -0400, James Kuyper
> <jameskuyper@alumni.caltech.edu> wrote:
> 
>> On 7/15/24 18:51, Lawrence D'Oliveiro wrote:
> [silliness]
>> Keep in mind that, in text mode, the <stdio.h> library routines use '\n'
>> in memory to represent whatever platform-specific method is used in
>> files to indicate a new line. For example, that can be a simple '\n' on
>> typical Unix-like machines, '\n\r' or '\r\n' on other operating systems,
>> and on a number of older systems, it could be converted to and from a
>> fixed-size block with a character count at the the beginning of the
>> block. There's no requirement that it be the Unicode line feed character.
> 
> I never knew any older system that used a fixed-size block (or rather
> record, which in those days was not the same as block) AND prefix
> count in the same file, although OS/360 et seq used ONE of them.
> 
> And Tandem Enscribe used either offset or count fields (depending on
> structure) at _end_ of block, near but not adjacent to records, except
> for textfiles had prefix counts per line AND word (of nonblanks) --
> but the initial versions of their C implementation couldn't handle
> textfiles, so you had to convert them to and from 'data'.

The systems that I used that needed that ability didn't put a length at 
the beginning of each block, but ALL the blocks were a fixed size in 
length (perhaps 80 characters) and shorter records were just filled out 
with spaces after the data (thus, the records were images of the 80 
column punched cards that would always have 80 columns of data).

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

#387787

On 8/25/24 16:55, dave_thompson_2@comcast.net wrote:
> On Mon, 15 Jul 2024 19:49:08 -0400, James Kuyper
> <jameskuyper@alumni.caltech.edu> wrote:
>
>> On 7/15/24 18:51, Lawrence D'Oliveiro wrote:
> [silliness]
>> Keep in mind that, in text mode, the <stdio.h> library routines use '\n'
>> in memory to represent whatever platform-specific method is used in
>> files to indicate a new line. For example, that can be a simple '\n' on
>> typical Unix-like machines, '\n\r' or '\r\n' on other operating systems,
>> and on a number of older systems, it could be converted to and from a
>> fixed-size block with a character count at the the beginning of the
>> block. There's no requirement that it be the Unicode line feed character.
>
> I never knew any older system that used a fixed-size block (or rather
> record, which in those days was not the same as block) AND prefix
> count in the same file, although OS/360 et seq used ONE of them.
>
> And Tandem Enscribe used either offset or count fields (depending on
> structure) at _end_ of block, near but not adjacent to records, except
> for textfiles had prefix counts per line AND word (of nonblanks) --
> but the initial versions of their C implementation couldn't handle
> textfiles, so you had to convert them to and from 'data'.

It's been a long time since I ever worked with systems that supported
such formats, and I never had to actually work with such formats, so I
don't really know a lot about them. I've figured out four different
schemes whereby a system using a fixed block size could keep track of
whether or not a text line stops inside the block, and if so, where; but
I'm not sure what methods were actually used, nor which systems used
them - but for me, the important point about all of those schemes is
that what the C standard fails to mandate about such things allows a
conforming implementation of C to use any one of them.

For most of my career as a programmer, I worked under requirements that
my code behave as intended on any hosted conforming implementation of C.
Since we didn't have any systems that used obscure line-ending methods
in shop, whether my code would have worked on such an implementation was
untested, but it was intended to.

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

#386804

On 7/6/24 7:49 AM, Thiago Adams wrote:
> If you were creating C code today and could use a C23 compiler, would 
> you use nullptr instead of NULL?
> 
> I am asking because I think I will keep using NULL.
> 
> I like nullptr semantics but I don't like to introduce new element 
> (nullptr) inside the code with no guarantee that the code will not mix 
> both.
> 
> In the past we also didn't have a guarantee we are not mixing 0 or NULL.
> 
> I think the best scenario for a team guideline would be a style warning 
> if 0 or nullptr is used and NULL to be defined as nullptr in a C23 
> compiler.
> 

The (small) problem with 0 or NULL being use is that in a context where 
you THINK you are passing a pointer, but the function actually is taking 
an integer value, 0 or NULL (defined as a 0) passes the syntax check.

If C23 REQURIED NULL to be defined as nullptr, then NULL would have been 
used, but as far as I know, it is still allowed to be defined as 0 
(unless you also have POSIX compatibility).

With POSIX Compatibility, where NULL must have the type of (void*) you 
also avoid the possible error, and thus the desire to use nullptr.

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

#386807

On 06/07/2024 16:39, Richard Damon wrote:
> On 7/6/24 7:49 AM, Thiago Adams wrote:
>> If you were creating C code today and could use a C23 compiler, would 
>> you use nullptr instead of NULL?
>>
>> I am asking because I think I will keep using NULL.
>>
>> I like nullptr semantics but I don't like to introduce new element 
>> (nullptr) inside the code with no guarantee that the code will not mix 
>> both.
>>
>> In the past we also didn't have a guarantee we are not mixing 0 or NULL.
>>
>> I think the best scenario for a team guideline would be a style 
>> warning if 0 or nullptr is used and NULL to be defined as nullptr in a 
>> C23 compiler.
>>
> 
> The (small) problem with 0 or NULL being use is that in a context where 
> you THINK you are passing a pointer, but the function actually is taking 
> an integer value, 0 or NULL (defined as a 0) passes the syntax check.
> 
> If C23 REQURIED NULL to be defined as nullptr, then NULL would have been 
> used, but as far as I know, it is still allowed to be defined as 0 
> (unless you also have POSIX compatibility).
> 
> With POSIX Compatibility, where NULL must have the type of (void*) you 
> also avoid the possible error, and thus the desire to use nullptr.

I hope that defining NULL as nullptr will become common - but I would be 
surprised to ever see it being required by C standards.

The ideal would be for C libraries to define NULL as nullptr and for C 
compilers to support a flag like gcc's "-Wzero-as-null-pointer-constant" 
warning (it is currently C++ only).  Then people can easily eliminate 
any mixup between integer 0 and null pointer constants by using that 
flag and either NULL or nullptr, according to taste.  (And those who 
don't want such checks, are not required to change.)

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

#386855

On Sat, 6 Jul 2024 18:57:08 +0200, David Brown wrote:

> ... and for C compilers to support a flag like gcc's "-Wzero-as-null
>-pointer-constant" warning ...

The trouble with compiler flags is they can never be part of any language 
spec.

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

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

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

csiph-web