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

[Jerry Leichter]

On Apr 23, 2014, at 6:06 PM, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> You are not programming in machine language.  Stop thinking that you
> are getting machine language semantics.
This is where C changes.  Way back when, before the first ANSI C, K&R (probably; I can't remember for certain now) had comments to the effect that certain things were "implementation defined" and the choices made by implementers were assumed to be such that programmers who understood the machine architecture would not be surprised.  Yes, K&R C had all kinds of ambiguities, and we went through a long an painful porting effort as people learned that "not everything is a VAX".  But for the most part, this approach worked reasonably well for the relatively small, highly experienced, audience that C addressed in those days.

As the C community grew, and more and more compilers came into existence on different machine architectures (back when there were more than three machine architectures) and different OS's (back when there were more than two OS's), stuff had to get formalized.  The first edition of the C spec did a pretty good job of pinning things down - but it was nice challenge at the time to write any useful code in purely conformant C.

The underlying issue here is:  While the C standards have advanced to the point where many things *are* possible in conformant C, the way it defines (more properly, chooses not to define) the semantics of signed overflow, it's impossible to write conformant, reasonably efficient C code that checks for signed overflow.  This is unfortunate, and really should be fixed:  Just as the standard these days lets you get at various special operations - like checking for NaN's in floating point - it should provide a standard way to check for signed overflow.  I don't know if there will ever be another version of the C standard, but if there is, the only way this kind of thing would stand a hope of getting included is for someone to define, and for large numbers of users and significant implementations to accept, a header file and a set of predicates or safe arithmetic functions or what have you that enable programmers to write safe code in the presence of signed arithmetic that might overflow.  Implementations can figure out how to support these.  They might simply provide an implementation compiled with all optimization turned off (verifying that for *their* implementation, that was safe).  They might provide an assembler implementation.  They might add built-ins.

Any of these is would be acceptable.  The current situation is ... absurd.  The compiler writers are sticking to the exact language of Standard, rather than worrying about what we used to call "quality of implementation" issues.

                                                        -- 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/20140423/f9dbc85c/attachment.bin>