[SystemSafety] Fwd: Re: Correcting the SECOND screw-up (grovelling apologies)

[Olwen Morgan]

On 14/07/2020 14:17, Derek M Jones wrote:
>
> I believe the following does not rely on undefined behavior (because
> conversion of negative values is defined for unsigned):
>
> #include <limits.h>
> #include <stdio.h>
>
> int main(void)
> {
> char ch=CHAR_MIN;
>
> if (ch < 0)
>    printf("char is signed\n");
> else
>    printf("char is unsigned\n");
>
> }

Technically speaking, Derek is right here.

But, as I once found in a system that suffered from what might be called 
"chaotic configuration management", it is quite easy for a C compiler to 
include an incorrect <limits.h> file. I'm thinking of a case at a Telco 
where a workstation cross-mounted via NFS, a set of C header files on 
another machine. When those changed, at the hands of a different system 
administrator, the baffling bugs ensued. The point of my program is that 
it attempts to make the determination in the execution environment. 
Derek's program takes the word of the implementation as given in the 
translation environment by <limits.h> at face value. This is not always 
a safe thing to do.

Nor is this language-lawyer nit-picking. On the C side of the iFacts 
project, I specifically advised Altran-Praxis not to rely on 
translation-environment processes to determine what the nature of 
implementation-specific characteristics was.

Nobody was going to come to grief because I hadn't done properly the job 
of ensuring that the major C checking tool (QAC) was correctly configured.


Olwen