Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #166921 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2022-07-22 12:32 -0700 |
| Last post | 2022-08-18 20:23 -0700 |
| Articles | 20 on this page of 87 — 20 participants |
Back to article view | Back to comp.lang.c
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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-07-31 17:40 +0100 |
| Message-ID | <87sfmh6xrw.fsf@bsb.me.uk> |
| In reply to | #167005 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 7/31/22 5:12 AM, David Brown wrote:
>> It is also not uncommon in microcontrollers for address zero to be a
>> useful address - and then it is user code that needs access. But it is rarely an issue in practice. The most common situation is having it as
>> part of the flash for code, and it is typically part of the interrupt vectors or reset vector. You would only want to read it for something
>> like a CRC check of the flash, and if you are concerned about the compiler handling a pointer to address zero in an unhelpful manner, you
>> can use a pointer-to-volatile. The other cases I have seen are having memory mapped peripherals there - and again, you always use volatile
>> accesses.
>
> And for machine specific case like this, the fact that derefencing a
> NULL pointer is "just" Undefined Behavior, that can be Implementaton
> Defined to do what is wanted, as opposed to some how PROHIBITED.
>
> *(char *0) = 0;
>
> Is a fully legal statement that must be translated.
>
> Yes, when you execute it, you get undefined behavior, but that might
> be just simply defined to write to location 0.
It doesn't /have/ to be translated (at least not to anything
meaningful). An implementation that uses location 0 might do the
obvious thing, but a compiler that translated that to puts("Sorry,
no."); would be conforming.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-31 12:56 -0400 |
| Message-ID | <NuyFK.783674$X_i.39111@fx18.iad> |
| In reply to | #167007 |
On 7/31/22 12:40 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 7/31/22 5:12 AM, David Brown wrote:
>>> It is also not uncommon in microcontrollers for address zero to be a
>>> useful address - and then it is user code that needs access. But it is rarely an issue in practice. The most common situation is having it as
>>> part of the flash for code, and it is typically part of the interrupt vectors or reset vector. You would only want to read it for something
>>> like a CRC check of the flash, and if you are concerned about the compiler handling a pointer to address zero in an unhelpful manner, you
>>> can use a pointer-to-volatile. The other cases I have seen are having memory mapped peripherals there - and again, you always use volatile
>>> accesses.
>>
>> And for machine specific case like this, the fact that derefencing a
>> NULL pointer is "just" Undefined Behavior, that can be Implementaton
>> Defined to do what is wanted, as opposed to some how PROHIBITED.
>>
>> *(char *0) = 0;
>>
>> Is a fully legal statement that must be translated.
>>
>> Yes, when you execute it, you get undefined behavior, but that might
>> be just simply defined to write to location 0.
>
> It doesn't /have/ to be translated (at least not to anything
> meaningful). An implementation that uses location 0 might do the
> obvious thing, but a compiler that translated that to puts("Sorry,
> no."); would be conforming.
>
And by that definition, ANY access to ANY specific location might not
work and be conforming.
The mapping of integer numbers to actually memory addresses is
implementation defined, and there is NO guarantee that any given address
can be created by code.
If you are writing code that needs to access specific addresses, you
need a compiler that defines the way to access those specific addresses,
and that includes acccessing location 0.
This is the way that Standard has always been. Some very useful stuff is
placed behind implementation dependency as that is simpler that adding a
lot of words for things that you might want on some systems but just
doesn't work on others.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-07-31 19:28 +0100 |
| Message-ID | <87mtcp6srv.fsf@bsb.me.uk> |
| In reply to | #167008 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 7/31/22 12:40 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 7/31/22 5:12 AM, David Brown wrote:
>>>> It is also not uncommon in microcontrollers for address zero to be a
>>>> useful address - and then it is user code that needs access. But it is rarely an issue in practice. The most common situation is having it as
>>>> part of the flash for code, and it is typically part of the interrupt vectors or reset vector. You would only want to read it for something
>>>> like a CRC check of the flash, and if you are concerned about the compiler handling a pointer to address zero in an unhelpful manner, you
>>>> can use a pointer-to-volatile. The other cases I have seen are having memory mapped peripherals there - and again, you always use volatile
>>>> accesses.
>>>
>>> And for machine specific case like this, the fact that derefencing a
>>> NULL pointer is "just" Undefined Behavior, that can be Implementaton
>>> Defined to do what is wanted, as opposed to some how PROHIBITED.
>>>
>>> *(char *0) = 0;
>>>
>>> Is a fully legal statement that must be translated.
>>>
>>> Yes, when you execute it, you get undefined behavior, but that might
>>> be just simply defined to write to location 0.
>> It doesn't /have/ to be translated (at least not to anything
>> meaningful). An implementation that uses location 0 might do the
>> obvious thing, but a compiler that translated that to puts("Sorry,
>> no."); would be conforming.
>i
> And by that definition, ANY access to ANY specific location might not
> work and be conforming.
>
> The mapping of integer numbers to actually memory addresses is
> implementation defined, and there is NO guarantee that any given
> address can be created by code.
I'm not sure why you think this is a problem. Sure, you can't pull any
value you like out of the air and assume that you can access it, but so
what? Any valid void * can be converted to, say, uintptr_t and back
again, so there /are/ integers that map to pointers in every conforming
implementation.
> If you are writing code that needs to access specific addresses, you
> need a compiler that defines the way to access those specific
> addresses, and that includes acccessing location 0.
Of course. I thought I covered that. Maybe I was unclear. If you need
access to specific location, your implementation should permit that.
> This is the way that Standard has always been. Some very useful stuff
> is placed behind implementation dependency as that is simpler that
> adding a lot of words for things that you might want on some systems
> but just doesn't work on others.
I think we may be agreeing with each other about most of this. I only
took issue with the notion that an undefined access must be translated
(and, by implication, translated "as expected").
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-31 14:52 -0400 |
| Message-ID | <wbAFK.94189$Lx5.91963@fx02.iad> |
| In reply to | #167009 |
On 7/31/22 2:28 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 7/31/22 12:40 PM, Ben Bacarisse wrote:
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 7/31/22 5:12 AM, David Brown wrote:
>>>>> It is also not uncommon in microcontrollers for address zero to be a
>>>>> useful address - and then it is user code that needs access. But it is rarely an issue in practice. The most common situation is having it as
>>>>> part of the flash for code, and it is typically part of the interrupt vectors or reset vector. You would only want to read it for something
>>>>> like a CRC check of the flash, and if you are concerned about the compiler handling a pointer to address zero in an unhelpful manner, you
>>>>> can use a pointer-to-volatile. The other cases I have seen are having memory mapped peripherals there - and again, you always use volatile
>>>>> accesses.
>>>>
>>>> And for machine specific case like this, the fact that derefencing a
>>>> NULL pointer is "just" Undefined Behavior, that can be Implementaton
>>>> Defined to do what is wanted, as opposed to some how PROHIBITED.
>>>>
>>>> *(char *0) = 0;
>>>>
>>>> Is a fully legal statement that must be translated.
>>>>
>>>> Yes, when you execute it, you get undefined behavior, but that might
>>>> be just simply defined to write to location 0.
>>> It doesn't /have/ to be translated (at least not to anything
>>> meaningful). An implementation that uses location 0 might do the
>>> obvious thing, but a compiler that translated that to puts("Sorry,
>>> no."); would be conforming.
>> i
>> And by that definition, ANY access to ANY specific location might not
>> work and be conforming.
>>
>> The mapping of integer numbers to actually memory addresses is
>> implementation defined, and there is NO guarantee that any given
>> address can be created by code.
>
> I'm not sure why you think this is a problem. Sure, you can't pull any
> value you like out of the air and assume that you can access it, but so
> what? Any valid void * can be converted to, say, uintptr_t and back
> again, so there /are/ integers that map to pointers in every conforming
> implementation.
>
>> If you are writing code that needs to access specific addresses, you
>> need a compiler that defines the way to access those specific
>> addresses, and that includes acccessing location 0.
>
> Of course. I thought I covered that. Maybe I was unclear. If you need
> access to specific location, your implementation should permit that.
>
>> This is the way that Standard has always been. Some very useful stuff
>> is placed behind implementation dependency as that is simpler that
>> adding a lot of words for things that you might want on some systems
>> but just doesn't work on others.
>
> I think we may be agreeing with each other about most of this. I only
> took issue with the notion that an undefined access must be translated
> (and, by implication, translated "as expected").
>
The key point is that *IF* the implementation defines how to access a
specific location of memory, and you use that method, then the
implementation must honor its definition.
That means that if they define how to convert a "number" to and address,
and don't exclude this working for address 0, then by that definition,
they can't "trap" accesses to the NULL pointer (if generating said null
pointer was done by the rules to access memory location 0).
The Standard may have left that access as explicit Undefined Behavior,
but by the implementation defining the Behavior, they need to honor
their definition.
Note uintprt_t might not exist, and might not be a simple mapping of
interger value to memory address, so that doesn't say that there exists
intergers that map to pointers on EVERY conforming implementation.
Yes, if uintptr_t exists, then every VALID pointer value can be
converted to an integer. This doesn't mean that every possible memory
address in the machine can be converted, as the program might not be
able to actually access every possible location in the machine (small
memory models in segmented architectures are an example).
There is also no promise that all values of a uintptr_t are valid pointers.
It also means that there might not be a value of uintptr_t to access
location 0 if the implementation doesn't consider a pointer to location
0 valid (and if it exists, it might not be the value 0).
So we get back to the point that we can only get defined access to
location 0 if the implementation defines it, and we do it in the way the
implementation defines.
Yes, for many implementations, that will end up being accessing through
a NULL pointer, but if we are to count on that working, the
implementation needs to define it, and if they define it, they need to
allow it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-07-31 21:35 +0100 |
| Message-ID | <87bkt56mwf.fsf@bsb.me.uk> |
| In reply to | #167010 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 7/31/22 2:28 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 7/31/22 12:40 PM, Ben Bacarisse wrote:
>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>
>>>>> On 7/31/22 5:12 AM, David Brown wrote:
>>>>>> It is also not uncommon in microcontrollers for address zero to be a
>>>>>> useful address - and then it is user code that needs access. But it is rarely an issue in practice. The most common situation is having it as
>>>>>> part of the flash for code, and it is typically part of the interrupt vectors or reset vector. You would only want to read it for something
>>>>>> like a CRC check of the flash, and if you are concerned about the compiler handling a pointer to address zero in an unhelpful manner, you
>>>>>> can use a pointer-to-volatile. The other cases I have seen are having memory mapped peripherals there - and again, you always use volatile
>>>>>> accesses.
>>>>>
>>>>> And for machine specific case like this, the fact that derefencing a
>>>>> NULL pointer is "just" Undefined Behavior, that can be Implementaton
>>>>> Defined to do what is wanted, as opposed to some how PROHIBITED.
>>>>>
>>>>> *(char *0) = 0;
>>>>>
>>>>> Is a fully legal statement that must be translated.
>>>>>
>>>>> Yes, when you execute it, you get undefined behavior, but that might
>>>>> be just simply defined to write to location 0.
>>>> It doesn't /have/ to be translated (at least not to anything
>>>> meaningful). An implementation that uses location 0 might do the
>>>> obvious thing, but a compiler that translated that to puts("Sorry,
>>>> no."); would be conforming.
>>> i
>>> And by that definition, ANY access to ANY specific location might not
>>> work and be conforming.
>>>
>>> The mapping of integer numbers to actually memory addresses is
>>> implementation defined, and there is NO guarantee that any given
>>> address can be created by code.
>> I'm not sure why you think this is a problem. Sure, you can't pull any
>> value you like out of the air and assume that you can access it, but so
>> what? Any valid void * can be converted to, say, uintptr_t and back
>> again, so there /are/ integers that map to pointers in every conforming
>> implementation.
>>
>>> If you are writing code that needs to access specific addresses, you
>>> need a compiler that defines the way to access those specific
>>> addresses, and that includes acccessing location 0.
>> Of course. I thought I covered that. Maybe I was unclear. If you need
>> access to specific location, your implementation should permit that.
>>
>>> This is the way that Standard has always been. Some very useful stuff
>>> is placed behind implementation dependency as that is simpler that
>>> adding a lot of words for things that you might want on some systems
>>> but just doesn't work on others.
>>
>> I think we may be agreeing with each other about most of this. I only
>> took issue with the notion that an undefined access must be translated
>> (and, by implication, translated "as expected").
>
> The key point is that *IF* the implementation defines how to access a
> specific location of memory, and you use that method, then the
> implementation must honor its definition.
Yes, we've both said this more than once. I wonder if there is any
disagreement...
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-08-15 23:24 -0700 |
| Message-ID | <86tu6cu2mw.fsf@linuxsc.com> |
| In reply to | #167010 |
Richard Damon <Richard@Damon-Family.org> writes: [...] > The key point is that *IF* the implementation defines how to > access a specific location of memory, and you use that method, > then the implementation must honor its definition. AFAIAA, the C standard does not require that implementations carry out their documented extensions correctly. We might like it to be so, but I don't see anything in the C standard that requires it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-07-31 16:57 -0700 |
| Message-ID | <875yjcx2cf.fsf@nosuchdomain.example.com> |
| In reply to | #167009 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> I'm not sure why you think this is a problem. Sure, you can't pull any
> value you like out of the air and assume that you can access it, but so
> what? Any valid void * can be converted to, say, uintptr_t and back
> again, so there /are/ integers that map to pointers in every conforming
> implementation.
[...]
A conforming implementation might not define [u]intptr_t. It still must
support conversions between pointers and integers, but the results of
such conversions might not be meaningful (other than the special case of
a null pointer constant).
--
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]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-07-31 16:55 -0700 |
| Message-ID | <87a68ox2fd.fsf@nosuchdomain.example.com> |
| In reply to | #167005 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 7/31/22 5:12 AM, David Brown wrote:
>> It is also not uncommon in microcontrollers for address zero to be a
>> useful address - and then it is user code that needs access. But it
>> is rarely an issue in practice. The most common situation is having
>> it as part of the flash for code, and it is typically part of the
>> interrupt vectors or reset vector. You would only want to read it
>> for something like a CRC check of the flash, and if you are
>> concerned about the compiler handling a pointer to address zero in
>> an unhelpful manner, you can use a pointer-to-volatile. The other
>> cases I have seen are having memory mapped peripherals there - and
>> again, you always use volatile accesses.
>
> And for machine specific case like this, the fact that derefencing a
> NULL pointer is "just" Undefined Behavior, that can be Implementaton
> Defined to do what is wanted, as opposed to some how PROHIBITED.
>
> *(char *0) = 0;
>
> Is a fully legal statement that must be translated.
No, it can be rejected at compile time. See the definition of
"undefined behavior":
NOTE Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance
of a diagnostic message), to terminating a translation or
execution (with the issuance of a diagnostic message).
> Yes, when you execute it, you get undefined behavior, but that might
> be just simply defined to write to location 0.
Certainly an implementation *can* do that, and it's what I'd want and
expect on an implementation where location 0 is usable.
Having location 0 be usable doesn't preclude using all-bits-zero to
represent a null pointer. It means you can't distinguish between a
valid pointer to location 0 and a null pointer, but in practice that's
not likely to be a huge problem; it just requires some care by the
programmer. Similarly, (time_t)-1 is an error value when returned by
the time() function, but it can also be a valid time, typically
1969-12-31 23:59:59 UTC.
--
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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-07-31 20:09 -0400 |
| Message-ID | <ZQEFK.590355$ssF.118034@fx14.iad> |
| In reply to | #167013 |
On 7/31/22 7:55 PM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 7/31/22 5:12 AM, David Brown wrote: >>> It is also not uncommon in microcontrollers for address zero to be a >>> useful address - and then it is user code that needs access. But it >>> is rarely an issue in practice. The most common situation is having >>> it as part of the flash for code, and it is typically part of the >>> interrupt vectors or reset vector. You would only want to read it >>> for something like a CRC check of the flash, and if you are >>> concerned about the compiler handling a pointer to address zero in >>> an unhelpful manner, you can use a pointer-to-volatile. The other >>> cases I have seen are having memory mapped peripherals there - and >>> again, you always use volatile accesses. >> >> And for machine specific case like this, the fact that derefencing a >> NULL pointer is "just" Undefined Behavior, that can be Implementaton >> Defined to do what is wanted, as opposed to some how PROHIBITED. >> >> *(char *0) = 0; >> >> Is a fully legal statement that must be translated. > > No, it can be rejected at compile time. See the definition of > "undefined behavior": > > NOTE Possible undefined behavior ranges from ignoring the > situation completely with unpredictable results, to behaving > during translation or program execution in a documented manner > characteristic of the environment (with or without the issuance > of a diagnostic message), to terminating a translation or > execution (with the issuance of a diagnostic message). But in this case, the Undefined Behavior occurs only at execution time, so unless the compiler can show that the statement MUST be executed (and maybe before executiong observable behavior, I forget it UB is allowed to time travel), it can't do anything at compile time. A file scope decleration like int bomb = *(int*)0; might allow a compile time rejection for undefined behavior. The Termination of Translation can ONLY apply to UB that has occured at translation time or possibly for execution time behavior that MUST happen, as otherwise the implementation have violated the requirements, since the UB hasn't happened yet, and might not ever happen. > >> Yes, when you execute it, you get undefined behavior, but that might >> be just simply defined to write to location 0. > > Certainly an implementation *can* do that, and it's what I'd want and > expect on an implementation where location 0 is usable. > > Having location 0 be usable doesn't preclude using all-bits-zero to > represent a null pointer. It means you can't distinguish between a > valid pointer to location 0 and a null pointer, but in practice that's > not likely to be a huge problem; it just requires some care by the > programmer. Similarly, (time_t)-1 is an error value when returned by > the time() function, but it can also be a valid time, typically > 1969-12-31 23:59:59 UTC. >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-08-15 22:52 -0700 |
| Message-ID | <867d38vio8.fsf@linuxsc.com> |
| In reply to | #167015 |
Richard Damon <Richard@Damon-Family.org> writes: > A file scope decleration like > > int bomb = *(int*)0; > > might allow a compile time rejection for undefined behavior. It's a constraint violation. The program may be rejected on that basis alone.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-16 09:21 +0200 |
| Message-ID | <tdfgi5$evg$1@dont-email.me> |
| In reply to | #167034 |
On 16/08/2022 07:52, Tim Rentsch wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> A file scope decleration like >> >> int bomb = *(int*)0; >> >> might allow a compile time rejection for undefined behavior. > > It's a constraint violation. The program may be rejected > on that basis alone. The only constraint I see for the indirection operator is in 6.5.3.2p2: """ The operand of the unary * operator shall have pointer type." """ (The constraints for casting are not violated either, as far as I can see.) The semantics for indirection say "If an invalid value has been assigned to the pointer, the behaviour of the unary * operator is undefined". A null pointer is mentioned in a footnote as an example of an invalid pointer, but it is not a constraint violation. Which constraint do you think the code line violates?
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2022-08-16 09:32 +0200 |
| Message-ID | <tdfh5u$s102$1@solani.org> |
| In reply to | #167040 |
Am 16.08.22 um 09:21 schrieb David Brown: > Which constraint do you think the code line violates? 6.7.10: "All the expressions in an initializer for an object that has static or thread storage duration or is declared with the constexpr storage-class specifier shall be constant expressions or string literals."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-16 11:06 +0200 |
| Message-ID | <tdfmml$10f4$1@dont-email.me> |
| In reply to | #167041 |
On 16/08/2022 09:32, Philipp Klaus Krause wrote: > Am 16.08.22 um 09:21 schrieb David Brown: >> Which constraint do you think the code line violates? > > 6.7.10: "All the expressions in an initializer for an object that has > static or thread storage duration or is declared with the constexpr > storage-class specifier shall be constant expressions or string literals." Ah, it is at file scope (and therefore static storage duration). I missed that. Thanks. It's easy to miss details of old threads with Tim's necroposting, but sometimes he has some subtle or interesting information that he is hiding, and there's a chance to learn something if it can be teased out of him.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-08-15 23:17 -0700 |
| Message-ID | <86y1vou2yp.fsf@linuxsc.com> |
| In reply to | #167005 |
Richard Damon <Richard@Damon-Family.org> writes: > On 7/31/22 5:12 AM, David Brown wrote: > >> It is also not uncommon in microcontrollers for address zero to be a >> useful address - and then it is user code that needs access. But it >> is rarely an issue in practice. The most common situation is having >> it as part of the flash for code, and it is typically part of the >> interrupt vectors or reset vector. You would only want to read it >> for something like a CRC check of the flash, and if you are >> concerned about the compiler handling a pointer to address zero in >> an unhelpful manner, you can use a pointer-to-volatile. The other >> cases I have seen are having memory mapped peripherals there - and >> again, you always use volatile accesses. > > And for machine specific case like this, the fact that derefencing a > NULL pointer is "just" Undefined Behavior, that can be Implementaton > Defined to do what is wanted, as opposed to some how PROHIBITED. Dereferencing a null pointer is unequivocally undefined behavior. It is never implementation-defined behavior. Even if an implementation defines and documents an extension that specifies a behavior for dereferencing a null pointer, as the C standard defines the terms such cases fall under the heading of undefined behavior, and not implementation-defined behavior.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-08-17 20:11 -0400 |
| Message-ID | <IsfLK.155213$El2.102395@fx45.iad> |
| In reply to | #167036 |
On 8/16/22 2:17 AM, Tim Rentsch wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> On 7/31/22 5:12 AM, David Brown wrote: >> >>> It is also not uncommon in microcontrollers for address zero to be a >>> useful address - and then it is user code that needs access. But it >>> is rarely an issue in practice. The most common situation is having >>> it as part of the flash for code, and it is typically part of the >>> interrupt vectors or reset vector. You would only want to read it >>> for something like a CRC check of the flash, and if you are >>> concerned about the compiler handling a pointer to address zero in >>> an unhelpful manner, you can use a pointer-to-volatile. The other >>> cases I have seen are having memory mapped peripherals there - and >>> again, you always use volatile accesses. >> >> And for machine specific case like this, the fact that derefencing a >> NULL pointer is "just" Undefined Behavior, that can be Implementaton >> Defined to do what is wanted, as opposed to some how PROHIBITED. > > Dereferencing a null pointer is unequivocally undefined behavior. > It is never implementation-defined behavior. Even if an > implementation defines and documents an extension that specifies > a behavior for dereferencing a null pointer, as the C standard > defines the terms such cases fall under the heading of undefined > behavior, and not implementation-defined behavior. Note, I didn't say that it was "Implementation Defined Behavior", but Undefined Behavior that the implementation can define. 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-17 20:08 -0700 |
| Message-ID | <87v8qqb64e.fsf@nosuchdomain.example.com> |
| In reply to | #167052 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 8/16/22 2:17 AM, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
[...]
>>> And for machine specific case like this, the fact that derefencing a
>>> NULL pointer is "just" Undefined Behavior, that can be Implementaton
>>> Defined to do what is wanted, as opposed to some how PROHIBITED.
>> Dereferencing a null pointer is unequivocally undefined behavior.
>> It is never implementation-defined behavior. Even if an
>> implementation defines and documents an extension that specifies
>> a behavior for dereferencing a null pointer, as the C standard
>> defines the terms such cases fall under the heading of undefined
>> behavior, and not implementation-defined behavior.
>
> Note, I didn't say that it was "Implementation Defined Behavior", but
> Undefined Behavior that the implementation can define.
You use the phrase "Implementation Defined", which is close enough to
the standard-defined term "implementation-defined behavior" (the
standard also defines "implementation-defined value") that it's almost
guaranteed to cause confusion.
I presume you know what "implementation-defined behavior" means, but the
above could easily have been written by someone who incorrectly thinks
it means "behavior that is defined by the implementation".
> 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.
Agreed.
--
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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-08-17 23:19 -0400 |
| Message-ID | <1diLK.269146$vZ1.129944@fx04.iad> |
| In reply to | #167053 |
On 8/17/22 11:08 PM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 8/16/22 2:17 AM, Tim Rentsch wrote: >>> Richard Damon <Richard@Damon-Family.org> writes: > [...] >>>> And for machine specific case like this, the fact that derefencing a >>>> NULL pointer is "just" Undefined Behavior, that can be Implementaton >>>> Defined to do what is wanted, as opposed to some how PROHIBITED. >>> Dereferencing a null pointer is unequivocally undefined behavior. >>> It is never implementation-defined behavior. Even if an >>> implementation defines and documents an extension that specifies >>> a behavior for dereferencing a null pointer, as the C standard >>> defines the terms such cases fall under the heading of undefined >>> behavior, and not implementation-defined behavior. >> >> Note, I didn't say that it was "Implementation Defined Behavior", but >> Undefined Behavior that the implementation can define. > > You use the phrase "Implementation Defined", which is close enough to > the standard-defined term "implementation-defined behavior" (the > standard also defines "implementation-defined value") that it's almost > guaranteed to cause confusion. > > I presume you know what "implementation-defined behavior" means, but the > above could easily have been written by someone who incorrectly thinks > it means "behavior that is defined by the implementation". > >> 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. > > Agreed. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-08-18 07:03 +0000 |
| Message-ID | <20220817235255.957@kylheku.com> |
| In reply to | #167054 |
On 2022-08-18, Richard Damon <Richard@Damon-Family.org> wrote: > On 8/17/22 11:08 PM, Keith Thompson wrote: >> Richard Damon <Richard@Damon-Family.org> writes: >>> On 8/16/22 2:17 AM, Tim Rentsch wrote: >>>> Richard Damon <Richard@Damon-Family.org> writes: >> [...] >>>>> And for machine specific case like this, the fact that derefencing a >>>>> NULL pointer is "just" Undefined Behavior, that can be Implementaton >>>>> Defined to do what is wanted, as opposed to some how PROHIBITED. >>>> Dereferencing a null pointer is unequivocally undefined behavior. >>>> It is never implementation-defined behavior. Even if an >>>> implementation defines and documents an extension that specifies >>>> a behavior for dereferencing a null pointer, as the C standard >>>> defines the terms such cases fall under the heading of undefined >>>> behavior, and not implementation-defined behavior. >>> >>> Note, I didn't say that it was "Implementation Defined Behavior", but >>> Undefined Behavior that the implementation can define. >> >> You use the phrase "Implementation Defined", which is close enough to >> the standard-defined term "implementation-defined behavior" (the >> standard also defines "implementation-defined value") that it's almost >> guaranteed to cause confusion. >> >> I presume you know what "implementation-defined behavior" means, but the >> above could easily have been written by someone who incorrectly thinks >> it means "behavior that is defined by the implementation". >> >>> 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. >> >> Agreed. >> > > 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. Isn't the above-discussed word "extension" it? "A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program". and all that. A predictable, catchable SIGSEGV signal being generated upon a null pointer dereference (or at least one not sufficiently displaced away from null), is an example of an extension. Does it not suffice? -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-08-23 09:43 -0700 |
| Message-ID | <86czcqud05.fsf@linuxsc.com> |
| In reply to | #167052 |
Richard Damon <Richard@Damon-Family.org> writes: > On 8/16/22 2:17 AM, Tim Rentsch wrote: > >> Richard Damon <Richard@Damon-Family.org> writes: >> >>> On 7/31/22 5:12 AM, David Brown wrote: >>> >>>> It is also not uncommon in microcontrollers for address zero to be a >>>> useful address - and then it is user code that needs access. But it >>>> is rarely an issue in practice. The most common situation is having >>>> it as part of the flash for code, and it is typically part of the >>>> interrupt vectors or reset vector. You would only want to read it >>>> for something like a CRC check of the flash, and if you are >>>> concerned about the compiler handling a pointer to address zero in >>>> an unhelpful manner, you can use a pointer-to-volatile. The other >>>> cases I have seen are having memory mapped peripherals there - and >>>> again, you always use volatile accesses. >>> >>> And for machine specific case like this, the fact that derefencing a >>> NULL pointer is "just" Undefined Behavior, that can be Implementaton >>> Defined to do what is wanted, as opposed to some how PROHIBITED. >> >> Dereferencing a null pointer is unequivocally undefined behavior. >> It is never implementation-defined behavior. Even if an >> implementation defines and documents an extension that specifies >> a behavior for dereferencing a null pointer, as the C standard >> defines the terms such cases fall under the heading of undefined >> behavior, and not implementation-defined behavior. > > Note, I didn't say that it was "Implementation Defined Behavior", but > Undefined Behavior that the implementation can define. The C standard frequently uses the adjectival phrase "implementation defined" (normally with a hyphen) to mean implementation-defined behavior. I understand the point you're trying to make. My complaint is not with the point but with the language you are using to express it. > 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. > [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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-23 11:02 -0700 |
| Message-ID | <871qt6zvm2.fsf@nosuchdomain.example.com> |
| In reply to | #167152 |
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.
For unspecified and not implementation-defined behavior, the choice of
actual behavior might not even be deliberate.
>> [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).
--
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]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web