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

Groups > comp.lang.c > #166982

Re: New features added into C23 standard

Show all headers | View raw

Richard Damon <Richard@Damon-Family.org> writes:

> On 7/28/22 7:02 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>> 
>>> On 7/26/22 8:24 AM, Malcolm McLean wrote:
>>>> On Tuesday, 26 July 2022 at 12:04:53 UTC+1, Richard Damon wrote:
>>>>> On 7/26/22 1:59 AM, Malcolm McLean wrote:
>>>>>> On Monday, 25 July 2022 at 22:50:41 UTC+1, Keith Thompson wrote:
>>>>>>> Thiago Adams <thiago...@gmail.com> writes:
>>>>>>>> On Monday, July 25, 2022 at 5:49:30 PM UTC-3, Thiago Adams wrote:
>>>>>>>>> It's hard to believe how nullptr was accepted.
>>>>>>>>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm
>>>>>>>>> The same for auto and constexpr.
>>>>>>>>
>>>>>>>> In 2018 I suggested nullptr
>>>>>>>>
>>>>>>>> https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/DJzGmwXmCQAJ
>>>>>>>>
>>>>>>>> In 2019 I replied my own message saying that was a bad idea.
>>>>>>>> https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/Daz0AvxHAwAJ
>>>>>>>>
>>>>>>>> I agree with myself from 2019.
>>>>>>>> "
>>>>>>>> One difference between adding _Bool into the language is that BOOL
>>>>>>>> was never added into the language headers. (Am I right? I didn't find
>>>>>>>> BOOL or TRUE FALSE at the language specification).
>>>>>>>>
>>>>>>>> On the other hand if you search for NULL at the standard you will
>>>>>>>> find that NULL is defined in stddef.h
>>>>>>>>
>>>>>>>> This means that adding _Bool didn't added a new way to declare booleans,
>>>>>>>> but adding nullptr will create this confusion that is two ways of
>>>>>>>> writing code that means NULL.
>>>>>>>>
>>>>>>>> In C we also have different ((void*)0) conversion rules compared with
>>>>>>>> C++ that is more strict.
>>>>>>>>
>>>>>>>> Then for C, I believe that the literal that corresponds nullptr already
>>>>>>>> exists and it is ((void*)0).
>>>>>>>>
>>>>>>>> What could be done is adding flags to static analysis to decide what
>>>>>>>> to do with ((void*)0) conversions.
>>>>>>>> "
>>>>>>> I don't see the problem. There are already arbitrarily many ways to
>>>>>>> write a null pointer constant in C. For example, '\0' '-'-'-', and
>>>>>>> 0x0ULL are all null pointer constants.
>>>>>>>
>>>>>>> A null pointer constant can be of any integer type, or of type void*.
>>>>>>>
>>>>>>> Adding nullptr and nullptr_t adds one more form of null pointer
>>>>>>> constant, and an unambiguous type for nullptr. Of course NULL and
>>>>>>> (void*)0 are still valid, because invalidating them would break tons of
>>>>>>> existing code -- but nullptr is the new preferred way to write a null
>>>>>>> pointer constant. Old code is still valid, but new code can be cleaner
>>>>>>> -- and if a user writes nullptr, there's no question that it was
>>>>>>> *intended* to be a null pointer constant, which could result in clearer
>>>>>>> diagnostic messages.
>>>>>>>
>>>>>>> (It's likely that if the language were being defined from scratch,
>>>>>>> nullptr would be the *only* way to write a null pointer constant. The
>>>>>>> stuff about using integer constant expressions exists only for backward
>>>>>>> compatibility, and we're stuck with it.)
>>>>>>>
>>>>>> There are two issues.
>>>>>> One is that on some architectures, writing to memory address zero is a
>>>>>> valid thing to do. Whilst you can argue that, in that case, a null pointer
>>>>>> should not be all bits zero, in reality it will be, and it will be obvious from
>>>>>> context where a write to address zero is intended.
>>>>>>
>>>>>> The other one is that you often have pointers embedded in structures,
>>>>>> which you zero-initialise. Again, you can argue that this is wrong because
>>>>>> a null pointer isn't necessarily all bits zero, but it is a widely used practice.
>>>>>> Also the struct s = {0}; syntax implies that null == zero, even though it
>>>>>> doesn't actually require that.
>>>>>>
>>>>> On many machines there isn't a pointer value that can't be used to
>>>>> access memory, so SOME address needs to be chosen.
>>>>>
>>>>> Also, on most machines, location 0 is unlikely to be data or a function
>>>>> to call, as it is defined by the archtecture to be something special, so
>>>>> a "user" program won't be dealing with a pointer to absolute location 0.
>>>>>
>>>> C requires that ptr + 1 be representable if ptr is valid. So on a 16
>>>> bit machine, 0xFFFF cannot be used as a valid char * (unless you
>>>> really do put the compiler through contortions). All bits set would
>>>> therefore be the obvious value to use for the null pointer.
>>>
>>> Is it required anywhere that the address+1 have a value > then the
>>> value
>> Something went wrong with this, I think!
>> 
>>> If not, a ptr value of all 1's could be a valid location, and the +1
>>> be the all 0's value. (likely requiring that this sort of pointer
>>> arithmetic act modulo like unsigned).
>>>
>>> I suppose doing this would break a lot of programs that assume that
>>> the ptr to end+1 is greater than all valid addresses in the array.
>> The first part is confusing so I am not sure what you are saying here,
>> but I think it needs clarifying.  That assumption, that end+1 will
>> compare greater than any pointer to an array element, is a valid
>> assumption, so breaking programs that make it would be wrong.
>
> The point is that just as all 0's could be a valid location to access,
> so could all 1's be a valid location.

All zeros is not an issue provided the compiler does the right thing
with mull pointers and the various conversions.

All ones is more problematic because a pointer just past the object at
that address must be valid and compare greater than the all ones
pointer.  This could be achieved by some very weird fiddling in the
implementation, but from the programmer's point of view, if you have a
valid object pointer p, p+1 must compare greater than p, though access
through p+1 is undefined.

> And, in fact, on some machines all ones might not be a valid address
> to put in a pointer for some types as it is mis-aligned, and just
> looking at a mis-aligned address might be a trapping operation.

Sure.  In those cases even all ones minus one would not be a valid place
to put an object because p+1 must always be a trap-free pointer (that
compares greater than p).

> IS it a valid assumption, does that Standard actually promise it?

Yes.

> I will admit, it is a common assumption, but as you point out, it
> means that the last location of memory can't be a valid location for
> an object, as ALL objects can be thought of as part of an array, and
> that array has a valid last loctation + 1 value.

All objects are not part of an array.  You can /think/ of them as being
part of some giant array, but you'd end up with undefined behaviour
depending on how you acted based on that model.  For example, the
standard defines <, <=, > and >= only for pointers to objects contained
in some larger C object.  Comparing

  int x, y;
  if (&x > &y) ...

is undefined by the language standard, even if you choose to think of
everything as being inside some larger object.

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-07-22 12:32 -0700
  Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-22 23:15 +0100
  Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-23 01:31 -0700
    Re: New features added into C23 standard gazelle@shell.xmission.com (Kenny McCormack) - 2022-07-23 10:10 +0000
  Re: New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-07-25 13:49 -0700
    Re: New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-07-25 13:57 -0700
      Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-25 14:50 -0700
        Re: New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-07-25 15:51 -0700
          Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-25 18:04 -0700
            Re: New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-07-25 19:23 -0700
              Re: New features added into C23 standard Opus <ifonly@youknew.org> - 2022-07-26 05:13 +0200
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-25 23:36 -0400
                Re: New features added into C23 standard Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-07-25 21:52 -0700
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 11:44 -0700
              Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 11:39 -0700
          Re: New features added into C23 standard David Brown <david.brown@hesbynett.no> - 2022-07-30 14:42 +0200
            Re: New features added into C23 standard scott@slp53.sl.home (Scott Lurndal) - 2022-07-30 15:18 +0000
              Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-30 09:13 -0700
            Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-30 17:31 +0100
              Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-30 16:46 -0700
            Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-30 14:36 -0700
              Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-30 18:15 -0400
                Re: New features added into C23 standard Kaz Kylheku <480-992-1380@kylheku.com> - 2022-07-30 23:28 +0000
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-31 16:48 -0700
                Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-31 22:42 -0700
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-31 23:25 -0700
                Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-01 00:10 -0700
                Re: New features added into C23 standard David Brown <david.brown@hesbynett.no> - 2022-08-01 09:55 +0200
                Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-01 20:17 +0100
              Re: New features added into C23 standard Kaz Kylheku <480-992-1380@kylheku.com> - 2022-07-30 23:21 +0000
        Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-25 22:59 -0700
          Re: New features added into C23 standard Öö Tiib <ootiib@hot.ee> - 2022-07-26 00:48 -0700
            Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-26 02:08 -0700
              Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-26 06:59 -0400
              Re: New features added into C23 standard Öö Tiib <ootiib@hot.ee> - 2022-07-26 04:02 -0700
                Re: New features added into C23 standard Vir Campestris <vir.campestris@invalid.invalid> - 2022-07-29 21:18 +0100
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-29 16:55 -0700
              Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 11:51 -0700
            Re: New features added into C23 standard David Brown <david.brown@hesbynett.no> - 2022-07-31 11:12 +0200
              Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-31 07:40 -0400
                Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-31 17:40 +0100
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-31 12:56 -0400
                Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-31 19:28 +0100
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-31 14:52 -0400
                Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-31 21:35 +0100
                Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 23:24 -0700
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-31 16:57 -0700
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-31 16:55 -0700
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-31 20:09 -0400
                Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 22:52 -0700
                Re: New features added into C23 standard David Brown <david.brown@hesbynett.no> - 2022-08-16 09:21 +0200
                Re: New features added into C23 standard Philipp Klaus Krause <pkk@spth.de> - 2022-08-16 09:32 +0200
                Re: New features added into C23 standard David Brown <david.brown@hesbynett.no> - 2022-08-16 11:06 +0200
                Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 23:17 -0700
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-08-17 20:11 -0400
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-17 20:08 -0700
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-08-17 23:19 -0400
                Re: New features added into C23 standard Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-18 07:03 +0000
                Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-23 09:43 -0700
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-23 11:02 -0700
                Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-23 13:40 -0700
          Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-26 07:04 -0400
            Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-26 05:24 -0700
              Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-26 22:30 -0400
                Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-29 00:02 +0100
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-28 21:20 -0400
                Re: New features added into C23 standard William Ahern <william@25thandClement.com> - 2022-07-28 19:36 -0700
                Re: New features added into C23 standard scott@slp53.sl.home (Scott Lurndal) - 2022-07-29 16:39 +0000
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-29 18:55 -0400
                Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-29 15:17 +0100
          Re: New features added into C23 standard scott@slp53.sl.home (Scott Lurndal) - 2022-07-26 13:27 +0000
          Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 11:47 -0700
            Re: New features added into C23 standard Kaz Kylheku <480-992-1380@kylheku.com> - 2022-07-26 20:27 +0000
              Re: New features added into C23 standard Philipp Klaus Krause <pkk@spth.de> - 2022-08-16 08:42 +0200
  Re: New features added into C23 standard Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-26 05:37 +0200
    Re: New features added into C23 standard Lynn McGuire <lynnmcguire5@gmail.com> - 2022-07-28 16:47 -0500
      Re: New features added into C23 standard Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-29 07:14 +0200
        Re: New features added into C23 standard Vir Campestris <vir.campestris@invalid.invalid> - 2022-07-29 21:21 +0100
  Re: New features added into C23 standard Grant Mulholland <grantlmul@gmail.com> - 2022-08-13 22:21 -0700
    Re: New features added into C23 standard Lynn McGuire <lynnmcguire5@gmail.com> - 2022-08-15 21:21 -0500
      Re: New features added into C23 standard Bonita Montero <Bonita.Montero@gmail.com> - 2022-08-16 08:39 +0200
    Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 22:54 -0700
    Re: New features added into C23 standard Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-18 12:03 -0700
      Re: New features added into C23 standard "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-08-18 12:56 -0700
      Re: New features added into C23 standard William Ahern <william@25thandClement.com> - 2022-08-18 16:07 -0700
        Re: New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-08-18 18:47 -0700
          Re: New features added into C23 standard Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-18 20:23 -0700

csiph-web