Message-ID: <316C57C2.4DA3@public1.guangzhou.gd.cn>
Date: Thu, 11 Apr 1996 09:52:18 +0900
From: Wang TianXing <gztxwang AT public1 DOT guangzhou DOT gd DOT cn>
Organization: No Organization
MIME-Version: 1.0
To: Jethro Wright <Jetman AT gnn DOT com>
CC: djgpp AT delorie DOT com
Subject: Re: A Proper Cast for a Funtio
References: <199604101807 DOT OAA27559 AT mail-e2b-service DOT gnn DOT com>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit

Jethro Wright wrote:
>
>         John:  It's dealing w/ routines exactly like qsort() where
> I need fn casts.  qsort() wants something like this passed as the
> last param:  (int (*) (const void *, const void *)).  Let's say
> I have a comparison fn that looks almost like that, exc that its
> params don't have the const attr.  Ok, I use a cast to tell the
> compiler: go ahead and use my routine, bec *I* know it's okay.  No (real)
> conversion is done and things work exactly the way I want.

Yes, if your fn really doesn't change its parameters. (so, if it's
written by you, why don't you put two const's there?)  Otherwise your
program's behavior might be undefined.

>  Or perhaps
> my comparison routine returns a long or char value.  No prob, the
> cast is safe and there *is* an implicit conversion (ie. truncation
> or sign extension), but *I* know it's safe for the compiler to do.

Unsafe, at least for the case that your fn returns a char.  Actually,
there is NO implicit convertion.  What will happen is that something
is viewed as some other type of thing.  This is never regarded as a
convertion:  your fn is returning a char, so the compiled code puts
the return value in AL, and returns.  Qsort() is expecting an int, so
it checks EAX.  Anyway, the high-order 24 bits of EAX could be
garbage, it could be neither signed, nor unsigned extended.

Similar discussion on parameters goes.

> If my comparison routine returned an unsigned, that would be an
> example of an unsafe cast, in this example, since the results of
> certain comparisons could never be passed back to qsort().  If my
> comparison fn spec'd formal args of float *, instead of void *,
> again usg a cast would be no prob.  Other explicit type coercions and
> implicit conversions must be evaluated on a case-by-case basis, since
> beyond the rules governing sign-extension and truncation of fractions
> (ie. bet integral and/or floating pt types), one is always on unstable
> ground, even if one can force the compiler to comply w/ one's wishes.
> 

Agreed, except those about truncation and sign-extension.
 
>         BTW:  I've been meaning to get a copy of the official ANSI C
> std for a while (Standard C by Brodie and Plauger has always served me
> well, but having the definitive ref is preferable), but I never seem to
> remember to order it from ANSI.  Does anyone know of a FTP site where
> I could simply d/l it as a Postscript or ASCII text file, if such an
> animal exists ?

You may have to order the C standard from ANSI, because selling
standards is its (only?) way to make profits.  That's what I've heard.
BTW, there're several draft C++ standards on the net.

---
Wang TianXing