Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #166979
| Message-ID | <8ntbri-4er.ln1@wilbur.25thandClement.com> (permalink) |
|---|---|
| From | William Ahern <william@25thandClement.com> |
| Subject | Re: New features added into C23 standard |
| Newsgroups | comp.lang.c |
| References | (5 earlier) <cTPDK.693216$X_i.668712@fx18.iad> <45c77994-d5f3-4514-88d1-f169b3cfb4bdn@googlegroups.com> <Wq1EK.513947$ssF.199505@fx14.iad> <87ilngq1r6.fsf@bsb.me.uk> <YBGEK.738163$JVi.469615@fx17.iad> |
| Date | 2022-07-28 19:36 -0700 |
Richard Damon <Richard@damon-family.org> wrote:
> 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.
>
> 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.
>
> IS it a valid assumption, does that Standard actually promise it? 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.
If you mean "ALL objects can be thought of as part of [the same] array",
then you're wrong. Relational operators like ">" aren't defined for objects
that aren't contained within the same aggregate object (arrays and
structures), and more importantly they're not defined for the null pointer;
only "==" is defined for the null pointer. We can't arrive at a place where
this relationship could matter.
Nonetheless, it stands to reason that whatever the valid values for a null
pointer, their representation(s) must be distinguishable from any valid
object pointer value, though only for the purposes of testing equality "=="
using validly derived operands. This restriction might be relevant to how
objects are allocated (i.e. to malloc), but it might not be--the
representation needn't be visible within the runtime environment, not even
through type punning or char pointer introspection.
Consider the CHERI project, which transparently utilizes an address tagging
scheme, 1 bit of which isn't addressable or visible. (Pointers logically
have 129 bits, but only 128 bits are represented in addressable--directly or
indirectly--memory.) Using a similar tagging scheme, I could imagine a
system where a null pointer could have any and every visible representation,
it's null'ness signaled by its out-of-band tag. This might cause headaches
with conversions to intptr_t, but strictly speaking intptr_t is optional,
and if it was supported than naturally that would imply something about the
size of the addressable space or the size of intptr_t relative to object
pointer types.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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