Good afternoon!
Since C23 clarified the wording of the description of the generic
selection feature, i.e. _Generic, originally introduced in C11, it is
now obvious that SDCC's current implementation of generic selection
deviates from the standard in the following ways:
SDCC currently ignores all qualifiers when comparing types in _Generic.
The C standard does however require that:
"If the generic controlling operand is an assignment expression, the
controlling type of the generic selection expression is the type of the
assignment expression as if it had undergone an lvalue conversion, array
to pointer conversion, or function to pointer conversion. Otherwise, the
controlling type of the generic selection expression is the type
designated by the type name."
I.e. the types in generic associations should not be touched, and our
implementation (which does) cannot inspect qualifiers (such as
const-ness) of pointee types, but should be able to.
Problems with default const-ness in SDCC
Addressing these issues did however reveal further deviations from
standard compliance in SDCC's type system or type handling, namely:
Firstly, for historical reasons, ANSI and ISO C have always required
string literals to be arrays of char rather than const char. In SDCC,
string literals are arrays of const char, like in C++. Consequently,
their type is considered different in the context of the standard
compliant _Generic, which led to regression test failures.
Secondly, SDCC supports the named address space __code for some of its
target architectures. Where this address space is read-only, SDCC
implicitly makes objects therein const, which does superficially make
sense, but interferes with _Generic-like type introspection. Whether the
C standard combined with the Embedded C TR allows an address space
qualifier to imply a const qualifier is very dubious and it is
reasonable to presume that it does not. This, too, led to regression
test failures with the repaired _Generic.
Proposed solution
For the sake of standard compliance, I would like to hereby suggest to
make both, string literals and objects in __code, non-const by default,
resolving the issues described above. To aid writing bug-free code, I
would have SDCC emit a warning whenever an object in read-only __code
space is not explicitly const, and also for pointers to such objects.
The command line options --fconst-str and --fconst-code would be added
for use cases where precisely matching the behavior of earlier SDCC
versions is desirable.
It seems desirable to resolve these issues for the upcoming 4.6.0 release.
Please let me know your opinions on the proposed solution.
Greetings,
Benedikt
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
