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

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

New features added into C23 standard

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

Contents

  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

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

#167164

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Richard Damon <Richard@Damon-Family.org> writes:
>
> [...]
>
>>> The implementation can define ANYTHING it wants (as an extension), as
>>> long as it doesn't violate a requirement of the Standard, and the
>>> Standard explicitly provides no requirement on things it declares to
>>> be Undefined Behavior, so an Implementation is free to define that
>>> behavior as anything.
>>
>> Any construct that an implementation compiles, it defines.  The behavior
>> can be defined explicitly by documenting an extension, or it can be
>> defined implicitly by what the generated code actually does.  Either
>> way, the implementation defines the behavior, but the point you are
>> trying to make is not that.
>
> You can put it that way if you like, but the standard uses the
> term "implementation-defined" specifically to refer to things that must
> be documented, and "unspecified" to refer to things that may or may not
> have to be documented.

Yes, the C standard uses the terms "implementation-defined behavior"
and "unspecified behavior" with very specific meanings, along with
the corresponding shortenings "implementation-defined" and
"unspecified".  My point is to distinguish the usage of words
"define" and "document" as they occur in ordinary English, and also
to avoid using phrases that might be confused with how similar
phrases are used in the C standard.

> For unspecified and not implementation-defined behavior, the
> choice of actual behavior might not even be deliberate.

Sure.  What behavior results might be an accidental, unconscious,
unaware, unknowing, or even unexpected and unintended consequence of
how the compiler is written.  It is still the case that the compiler
implicitly defines the behavior, by virtue of what choices are made
to produce the compiled code.

>>> [from a later posting]
>>> Yes, unfortunately, the language of the Standard doesn't give a good
>>> term for things the Implementation chooses to define but wasn't
>>> required to define.
>>
>> Yes, it does.  An implementation can document an extension that
>> specifies the behavior of the construct in question.
>
> An implementation might, for example, document the order of evaluation
> of the operands to "+".  I don't think that would be considered an
> extension (though the standard doesn't define the term "extension"
> precisely).

To my way of thinking any specification of behavior that goes beyond
what the C standard mandates counts as an extension (provided of
course it is documented), regardless of whether the additional
semantics falls into the realm of unspecified behavior, undefined
behavior, or even contradicts what the C standard says (assuming of
course the change has no effect on any strictly conforming program).
If the implementation wants to say that some additional semantic
rules are in effect then that needs to be documented somewhere, and
the only kinds of such documentation mentioned in the C standard are
for implementation-defined behavior, and for extensions.

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

#166953

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.

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

#166957

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.

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

#166968

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

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.

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

#166977

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.

-- 
Ben.

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

#166978

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.

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

#166979

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.

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

#166984

William Ahern <william@25thandClement.com> writes:
>Richard Damon <Richard@damon-family.org> wrote:

>
>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.)

In Cheri they're more than pointers, they're capabilities that describe
the bounds and access constraints along with the memory address.

Specifically, the implementation is required to support one extra bit
for each 128-bits of DRAM.    This can be out-of-band (i.e. a DRAM
region not visible to the CPU load/store instructions) or with special
DIMMs (pointers must be 128-bit aligned).

The bit indicates that the corresponding 128-bit region contains a
capability (and can only be modified using specific instructions).


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

In CHERI, a NULL pointer has a specific representation in the
capability (which is not necessarily all zeros or all ones).

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

#166989

On 7/28/22 10:36 PM, William Ahern wrote:
> 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.

Nope, the fact that all objects, even if not in an explicit array, can 
be thought of as a member of an array of size 1, and thus that "address 
+ 1" of that object is valid.

Thus for ANY object, (&obj)[0] references the object, and &((&obj)[1]) 
is a valid address, as the one past end of an array.

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

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

#166982

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.

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

#166958

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Monday, 25 July 2022 at 22:50:41 UTC+1, Keith Thompson wrote:
>> Thiago Adams <thiago...@gmail.com> writes: 
>
>> 
>> (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.

Indeed, I worked on one system where the a NULL pointer was defined (by hardware) as a
32-bit (8 digit) field where the low-order 24 bits (6 digits) are all ones.

The search linked list (SLT) instruction could return a NULL pointer
on a miss, for example.

The system never had a C compiler, but had a Modula-like HLL called SPRITE.

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

#166962

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> 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.

Adding nullptr to the language has nothing to do with that issue.  All
the existing forms of null pointer constant are still valid.

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

In other words, if you incorrectly assume that a null pointer is
all-bits-zero, you can make mistakes.

No, `struct s obj = {0};` doesn't imply anything about the
representation of a pointer -- at least not to someone who knows
the language well enough.  Nor does it imply anything about the
representation of floating-point 0.0, which also is not guaranteed
to be all-bits-zero.  And again, adding nullptr has nothing to do
with this.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#166964

On 2022-07-26, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
>> 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.
>
> Adding nullptr to the language has nothing to do with that issue.  All
> the existing forms of null pointer constant are still valid.
>
>> 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.
>
> In other words, if you incorrectly assume that a null pointer is
> all-bits-zero, you can make mistakes.

It's possible that you can assume that a pointer is all zero bits,
and never be actually incorrect for your entire programming career.

> No, `struct s obj = {0};` doesn't imply anything about the
> representation of a pointer -- at least not to someone who knows

The problem is that "struct s obj = { 0 }" is insecure if the image of s
can be communicated outside of the program; it doesn't guarantee that
the padding between struct members and at the end will be obliterated
with zeros, and those areas can leak information.

This is secure version (at least if we momentarily ignore the
squabbling about whether any memset call can actually be secure):

  struct s;
  memset(&s, 0, sizeof s);

Or else, get a fresh object from calloc. Of course, this sort
of hedge is possible:

  struct s;
  memset(&s, 0, sizeof s);
#if CONFIG_NULL_ISNT_ZERO
  s.ptr = NULL;
#endif

and other such. I've never seen it in the wild.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

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

#167039

Am 26.07.22 um 22:27 schrieb Kaz Kylheku:
> 
> (at least if we momentarily ignore the
> squabbling about whether any memset call can actually be secure):

You should use C23 memset_excplicit here.

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

#166941

Am 22.07.2022 um 21:32 schrieb Thiago Adams:
> -  nullptr
> - typed enumerations
> - improved normal enumerations
> - Comma omission and comma deletion
> - constexpr
> - auto
> - TIME_MONOTONIC
> - bit-precise bit-fields
> - relaxed requirements for variadic parameter lists
> - embed
> ...

I don't know why this language is still extended.
These are all concepts that can no longer be saved.
C is just a hopelessly outdated language.

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

#166976

On 7/25/2022 10:37 PM, Bonita Montero wrote:
> Am 22.07.2022 um 21:32 schrieb Thiago Adams:
>> -  nullptr
>> - typed enumerations
>> - improved normal enumerations
>> - Comma omission and comma deletion
>> - constexpr
>> - auto
>> - TIME_MONOTONIC
>> - bit-precise bit-fields
>> - relaxed requirements for variadic parameter lists
>> - embed
>> ...
> 
> I don't know why this language is still extended.
> These are all concepts that can no longer be saved.
> C is just a hopelessly outdated language.

Not for the embedded people.  They live by C and love it.

Lynn

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

#166981

Am 28.07.2022 um 23:47 schrieb Lynn McGuire:
> On 7/25/2022 10:37 PM, Bonita Montero wrote:
>> Am 22.07.2022 um 21:32 schrieb Thiago Adams:
>>> -  nullptr
>>> - typed enumerations
>>> - improved normal enumerations
>>> - Comma omission and comma deletion
>>> - constexpr
>>> - auto
>>> - TIME_MONOTONIC
>>> - bit-precise bit-fields
>>> - relaxed requirements for variadic parameter lists
>>> - embed
>>> ...
>>
>> I don't know why this language is still extended.
>> These are all concepts that can no longer be saved.
>> C is just a hopelessly outdated language.
> 
> Not for the embedded people.  They live by C and love it.

When I look at jobs for embedded developers I find more
jobs which ask for C++ skills than C only.

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

#166988

On 29/07/2022 06:14, Bonita Montero wrote:
> 
> When I look at jobs for embedded developers I find more
> jobs which ask for C++ skills than C only.

I just retired from the embedded world.

Although most of my last job was C++, a good knowledge of C was required.

Smaller systems tend to use C more. We had megabytes of store, not 
kilobytes.

It depends where you want your career to go.

Andy

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

#167028

On Friday, July 22, 2022 at 2:32:12 PM UTC-5, Thiago Adams wrote:
> - nullptr 
> - typed enumerations 
> - improved normal enumerations 
> - Comma omission and comma deletion 
> - constexpr 
> - auto 
> - TIME_MONOTONIC 
> - bit-precise bit-fields 
> - relaxed requirements for variadic parameter lists 
> - embed 
> ...
Good lord, auto in C...

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

#167033

On 8/14/2022 12:21 AM, Grant Mulholland wrote:
> On Friday, July 22, 2022 at 2:32:12 PM UTC-5, Thiago Adams wrote:
>> - nullptr
>> - typed enumerations
>> - improved normal enumerations
>> - Comma omission and comma deletion
>> - constexpr
>> - auto
>> - TIME_MONOTONIC
>> - bit-precise bit-fields
>> - relaxed requirements for variadic parameter lists
>> - embed
>> ...
> Good lord, auto in C...

I don't like it in C++ either.

Lynn

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

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

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

csiph-web