Re: aliasing

[David Brown <david.brown@hesbynett.no>]

On 18/03/2024 16:00, Martin Uecker via Gcc wrote:
> Am Montag, dem 18.03.2024 um 14:29 +0100 schrieb David Brown:
>>
>> On 18/03/2024 12:41, Martin Uecker wrote:
>>>
>>>
>>> Hi David,
>>>
>>> Am Montag, dem 18.03.2024 um 10:00 +0100 schrieb David Brown:
>>>> Hi,
>>>>
>>>> I would very glad to see this change in the standards.
>>>>
>>>>
>>>> Should "byte type" include all character types (signed, unsigned and
>>>> plain), or should it be restricted to "unsigned char" since that is the
>>>> "byte" type ?  (I think allowing all character types makes sense, but
>>>> only unsigned char is guaranteed to be suitable for general object
>>>> backing store.)
>>>
>>> At the moment, the special type that can access all others are
>>> all non-atomic character types.  So for symmetry reasons, it
>>> seems that this is also what we want for backing store.
>>>
>>> I am not sure what you mean by "only unsigned char". Are you talking
>>> about C++?  "unsigned char" has no special role in C.
>>>
>>
>> "unsigned char" does have a special role in C - in 6.2.6.1p4 it
>> describes any object as being able to be copied to an array of unsigned
>> char to get the "object representation".
>>   The same is not true for an
>> array of "signed char".  I think it would be possible to have an
>> implementation where "signed char" was 8-bit two's complement except
>> that 0x80 would be a trap representation rather than -128.  I am not
>> sure of the consequences of such an implementation (assuming I am even
>> correct in it being allowed).
> 
> Yes, but with C23 this is not possible anymore. I think signed
> char or char should work equally well now.

I have just noticed that in C23, the SCHAR_MIN is -128 (or -2 ^ (N-1) in 
general), eliminating the possibility of having a trap value for signed 
char (or any other integer type without padding bits).  There's always a 
bit of jumping around in the C standards to get the complete picture!

But as I said in another post, I still worry a little about the unsigned 
to signed conversion being implementation-defined, and therefore not 
guaranteed to work in a way that preserves the underlying object 
representation.  I think it should be possible to make a small change to 
the description of unsigned to signed conversions to eliminate that.


>>
>> I see people making a lot of assumptions in their embedded programming
>> that are not fully justified in the C standards.  Sometimes the
>> assumptions are just bad, or it would be easy to write code without the
>> assumptions.  But at other times it would be very awkward or inefficient
>> to write code that is completely "safe" (in terms of having fully
>> defined behaviour from the C standards or from implementation-dependent
>> behaviour).  Making your own dynamic memory allocation functions is one
>> such case.  So I have a tendency to jump on any suggestion of changes to
>> the C (or C++) standards that could let people write such essential code
>> in a safer or more efficient manner.
> 
> That something is undefined does not automatically mean it is
> forbidden or unsafe.  It simply means it is not portable.  

That is the case for things that are not defined in the C standards, but 
defined elsewhere.  If the behaviour of a piece of code is not defined 
anywhere for the toolchain you are using, then it is inherently unsafe 
to use.  ("Forbidden" is another matter.  It might be "forbidden" by 
your coding standards, or your boss, but the language and tools don't 
forbid things!)

Something that is not defined in the C standards, but defined in your 
compiler manual or additional standards (such as POSIX) is safe to use 
but limited in portability.

And of course something that is "inherently unsafe" may be considered 
safe in practice, by analysing the generated object code or doing 
exhaustive testing.

> I think
> in the embedded space it will be difficult to make everything well
> defined.  

Yes, that is absolutely true.  (And it is even more difficult if you try 
to restrict yourself to things with full definitions in the C standards 
or explicit implementation-defined behaviour documented by toolchains. 
You almost invariably need some degree of compiler extensions for parts 
of the code.)

But I want to reduce to the smallest practical level the amount of code 
that "works in practice" rather than "known to work by design".

> But I fully agree that widely used techniques should
> ideally be based on defined behavior and we should  change the
> standard accordingly.
> 

Yes, where possible and practical, the standard provide the guarantees 
that programmers need.  Failing that, compiler extensions are good too - 
I'd be very happy with a GCC variable __attribute__ "backing_store" that 
could be applied to allocator backing stores and provide the aliasing 
guarantees needed.  (It might even be needed anyway, to work well with 
the "malloc" attribute, even with your change to the standard.)


David