Menu
▾
▴
#1003 _Optional qualifier
There is a proposal for C2Y for an _Optional qualifier (N3422), that can help protect users against using null pointers, where such pointers are not valid. This will likely become a TR before it becomes part of the C standard itself, but I don't expect the TR (or a version going into some C3x standard) to be much different from N3422. IMO, SDCC should support _Optional to help users write safer firmware.
Related
Support for the Qualifier as such has been implemented in the _Optional branch, and was merged to trunk in [r15909]. The implementation follows N3422, but N3422 is somewhat unclear on some details wrt. arrays, where the examples give apparently contradict the proposed normative text, so there are probably some details to work out after possible clarification.
Also, there is no support yet for any diagnostics based on the combination of _Optional with information from static analysis, in particular generalized constant propagation.
Related
Commit: [r15909]
In [r15945], the _Optional branch has been merged to trunk a second time, which brought some bugfixes and diagnostics based on data-flow / generalized constant propagation analysis. Some of the details in N3422 are still a bit unclear (wrt. _Optional on array parameters that decay to pointers, and some other corner-cases for arrays), not sure if that can be resolved before there is an official TR/TS for _Optional replacing N3422.
Related
Commit: [r15945]
The first regression test results from the compile farm post-merge are in (GNU/Linux on ppc64). Tests pass. However, we do have a code size regression for mcs51 and z80 in benchmarks (interestingly not for r3ka and stm8).
I'll have to look into that. Obvious candidates would be changes to cast handling (necessary to properly preserve the _Optional qualifier until after the second round of generalized constant propagation, i.e part of the fix for [bugs:#3898]), and the changes in generalized constant propagation. Both were ultimately part of implementing data-flow based diagnostics based on the _Optional qualifier.
Related
Bugs: #3898
For z80, this was due to the va_args changes resulting in small differences for the printf_large function (which is part of printf, and thus used in all benchmarks), resulting in different register allocation, which happened to result in less efficient code (85B code size regression). Not much to be done about that in principle, but in [r15957], I implemented some improvements, that brought the printf_large code size regression down to 35B, which looks good enough to me (after all we do get some improvements in other functions, so in the end benchmark code sizes are fine).
Related
Commit: [r15957]
For mcs51, like z80, the va_args changes result in slightly different register allocation, which then results in a 111B bigger printf_large, which is included in all benchmarks via printf. The main problem is apparently that the variable c is allocated to the stack instead of a register, at the switch statement, which results in much bigger code there (and somewhat smaller code elsewhere, but not enough to compensate).
The current _Optional TS draft has changed somewhat vs. N3422. A first round of changes/fixes went into trunk in [r16327]. I am currently working on another round of changes/fixes in the _Optional branch, and hope to have it ready later this week, so it can go into trunk before SDCC 4.6.0.
Related
Commit: [r16327]
Those fixes are in: [r16372].
Related
Commit: [r16372]