Message-Id: <199604091541.LAA31790@mail-e2b-service.gnn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 09 Apr 1996 11:46:44
From: Jethro Wright <Jetman AT gnn DOT com>
To: djgpp AT delorie DOT com
Subject: Re: A Proper Cast for a Funtion Ptr....

>Date:	Tue, 9 Apr 1996 11:21:49 +0200 (IST)
>From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
>Sender:	eliz AT is
>To:	Jethro Wright <Jetman AT gnn DOT com>
>cc:	djgpp AT delorie DOT com
>Subject:	Re: A Proper Cast for a Funtion Ptr....
>
>
>On Mon, 8 Apr 1996, Jethro Wright wrote:
>
>> >But beware: when a C compiler sees this, it actually generates 
code to
>> >call `newfn' with a calling sequence that is appropriate for 
`oldfn'. In
>> >this case, it converts `s' from int to unsigned int, but other
>> >subtle things might be going on there too.  This is what casting
>> >function pointers means.  It's best to avoid it, unless you can't do
>> >otherwise.
>> 
>> 	Eli, it has always been my understanding that casts in
>> C *don't* do conversions (at least, for casts bet integral
>> types),
>
>This is NOT true for casting functions.  When you call a casted
>function, the stack and the variables it gets are set up according 
>to the cast.  Otherwise, casting function would have no effect at all,
>except escaping the compiler type-checks (which is not what it is 
>meant to do).

	Eli:  You're overlooking the fact that my orig question was
referring to a *C* program.  What you say (re: conversions via casts)
is 100% correct for a C++ program/fn, where the presence of the implicit
'this' ptr passed to class member fns *demands* an intermediate 
conversion, so that an instance of a class is bound to the appropriate
vtbl(s).  I think you got the wrong idea from the cast I posted:

	void newfn( u_int s, void *, void * )

	but u_int is just what it reads to be: an unsigned int, nothing
more.  This is the ideal example that demonstrates what I'm saying.
There can be no conversion bet an unsigned and a signed type of the
same size, so the compiler must assume that the consumer (programmer) 
is doing the right thing.  Were u_int an instance of a C++ class,
then the compiler would have to do some sort of conversion.  But outside
the C++ processing space, any interpretation of data being being coerced
to another type could result in subsequent and potentially 
castastrophic results, so the compiler must not intervene.  That's to
say, if newfn is not a C fn, but rather a routine in an external 
assembler module or inside the OS, the compiler could corrupt perfectly
valid data, if it does anything other than sign extension (or truncation,
in order to cast down to a smaller type) when a cast is requested.  Any
other type cast would be inherently unsafe and dangerous, so everything
would have to be re-coded to use some other data respresentation 
scheme.  This *must* be true, otherwise the ANSI std qsort() routine
couldn't work.

	Yes, in *C*, a cast is explicitly intended to override type 
checking.  That's even true in C++, w/ some important 
caveats/restrictions, but only to ensure "some" degree of integrity 
of the internal respresentation of class/instance data....    Jet


================================================================
  In Paris, they simply stared when I spoke to them in French;
  I never did succeed in making those idiots understand their
  own language.		- Mark Twain, The Innocent Abroad,1869
================================================================