[SystemSafety] Fwd: Re: Correcting the SECOND screw-up (grovelling apologies)
Olwen Morgan
olwen at phaedsys.com
Tue Jul 14 17:42:46 CEST 2020
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
More information about the systemsafety
mailing list