Mail Archives: djgpp/1996/04/10/14:14:26
>Date: Wed, 10 Apr 96 04:00:00 UTC 0000
>From: j DOT aldrich6 AT genie DOT com
>To: djgpp AT delorie DOT com
>Subject: Re: A Proper Cast for a Funtio
>
>Reply to message 2504589 from JETMAN AT GNN DOT CO on 04/09/96 2:15PM
>
>
>>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.
>
>That doesn't make any sense! What about integer to float conversions?
>If the compiler didn't do translation from one type to the other,
>it would result in chaos. (Imagine reading a 4-byte integer as an 8-byte
>double...)
>
>Or are you distinguishing between typecasting and promotion/demotion
>in expressions? I agree that to physically modify the data when
>performing a cast on a pointer type, for example, would be insane,
>but that isn't the idea anyway, is it? Besides, functions like qsort()
>don't actually perform any type-dependent operations on the lists they
>are passed - it's up to the comparison function to do that. And
typecasting to const void * is meaningless except to establish that a
>given piece of data is 'generic', and can actually be anything at all.
>That's the basic principle on which qsort(), etc.,work.
>
>John
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. 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.
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.
This is precisely what I've been refering to. IMHO, that's
what casting (type coercion) is *all* about, at least in C. One
really can't go wrong, as long as one stays w/in the constraints
detailed above.
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 ?
================================================================
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
================================================================
- Raw text -