[Cryptography] GCC bug 30475 (was Re: bounded pointers in C)

Jerry Leichter leichter at lrw.com
Thu May 1 15:45:53 EDT 2014


On May 1, 2014, at 3:16 PM, Bear <bear at sonic.net> wrote:
>> As I mentioned before, Java originally specified FP arithmetic this
>> tightly - and as a result compliant, reasonably efficient
>> implementations were *impossible* on tons of hardware.  The Java
>> community eventually backed off because this was an issue for so much
>> of what they decided was the Java audience; but when it comes to other
>> forms of integer arithmetic, they've effectively written off multiple
>> classes of machines.
> 
> At this point it's hard to say that C's treatment of such things 
> as 'undefined' is better.  Having semantics that can't be known 
> or checked is nearly as bad as working on a "written off" class
> of hardware.
That just means you can't write "portable, Standard-compliant" code on that hardware.  An implementation can specify any semantics it likes for things the Standard chooses to leave undefined.  A good implementation might include things like:

#define SIGNED_OVERFLOW_IS_2S_COMPLEMENT

in some include file, and you could then test for it.

An implementation clearly can't constrain whether *other* implementations #define this, in an include file with exactly the same name, to mean something else - but in practice this isn't likely.  (Many, many years ago, I knew someone who wrote FORTRAN programs that in case of a severe error did CALL ABORT.  There was no standard ABORT subroutine - but his argument was:  If there's no ABORT in the library, the program will die at run time - FORTRAN and linkers of the day didn't check earlier - with a call to an undefined entry point.  If there *is* a subroutine named ABORT in the library - what else could it possibly do?)

With luck and some community involvement, a include file of this sort, with a common, agreed-upon set of macros, could become widely available.  And then it might eventually even get into the next version of the C Standard.

On the other hand, no reasonable Java-compliant implementation is possible on a machine that only provides (say) 1's complement integers, or non-IEEE floats.

                                                        -- Jerry


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140501/7c08ac7f/attachment.bin>


More information about the cryptography mailing list