Mail Archives: djgpp/1996/04/10/22:55:39
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
- Raw text -