Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!yale!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Casting Function Pointers
Message-ID: <16271@smoke.brl.mil>
Date: 27 May 91 02:08:21 GMT
References: <1991May24.005025.7714@tkou02.enet.dec.com> <16259@smoke.brl.mil> <1991May25.221756.16182@zoo.toronto.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 20

In article <1991May25.221756.16182@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <16259@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>>I'm not aware of any changes between the final draft of K&R2 (first printing)
>>and the official C standard that would make K&R2 less correct...
>I know of at least one -- it's no longer promised that casting a pointer to
>integer and back preserves its value if the integer is big enough -- and
>there are probably a few more.

X3.159-1989 Section 3.3.4 Semantics require that there be some such
implementation-defined type.  Well, actually, it doesn't require that
the "before" and "after" pointers compare equal, but that is clearly
the intent, for implementations where this is even possible.  There
can be some implementations with, say, 128-bit addresses and 64-bit
data words, for which some information would necessarily be lost by
the transformation.  Thus, while K&R2 section A6.6 technically
promises more than the C standard requires, it does indicate what the
intended behavior is, for implementations for which it is feasible.

Was that really changed during the public review process?  I don't
have the old drafts to look it up in.