From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.misc
Subject: Re: Safety.  Was: Re: Pointers
Summary: inadequacy of unions not explained, why teach atypical applications first not explained
Date: 14 Dec 92 05:42:05 GMT

: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
: Message-ID: <Bz0Iy5.A9K@mentor.cc.purdue.edu>
: C does not allow type coercions.  I do not consider unions an adequate
: way to do that.

I have not seen any posting in which Herman explains *why* he does not
consider unions an adequate way to specify type punning, despite having
seen the claim that they *aren't* adequate several times.  (Type coercions
are something else, in standard usage.)

In particular, I'll quote an example from message
<723522717@sheol.UUCP>, and I would appreciate it if somebody would
explain what's so horrible or "inadequate" about the use of unions in
the example.  I'd especially appreciate comments on the last usage
below, involving inline functions. 

-- begin excerpt from <723522717@sheol.UUCP> --
 : Telling the compiler that that number which you used as an integer before
 : is now to be considered a float is not ambiguous, except that most of the
 : current languages will object strongly.
 
 "Most of the current languages" object strongly because THEY HAVE
 NO SUCH OPERATION.  Herman is simply using an operation that is
 MEANINGLESS IN THE LANGUAGE.
 
 Now, Ada, PL/I and C DO have such operations, and in the specific case
 of C, the compilers I've tried them out upon don't "object strongly".
 They don't object at all.  For example:
 
         void g(float);
         void f(void){
             union {float f; int i;} u;
             g((u.i=0xABCD,u.f));
         }
 
 This says, "take this number I've been treating as an int, treat it as
 a float, and pass it to g", quite clearly and fairly unambiguously.  Of
 course, Herman probably objects that this "syntax is clumsy", and
 presumably wishes to write something like
 
         void g(int);
         void f(void){
             g(0xABCD);
         }
 
 and then in a separate file, implement g like so
 
         void g(float){ ... }
 
 The problem with this is, the C compiler is not obliged to treat this as
 anything other than the gibberish (in the context of the C language)
 that it is.  And if the syntax of the correct way of expressing this in
 C is clumsy, one can (in gcc at least) implement the conversion as an
 inline function in an include file:
 
         inline float iasf(int i) {
             /* treat the bits of an integer as a float */
             union {long f; int i;} u;
             return(u.i=i,u.f);
         }
 
 and then use it where needed
 
         #include "taken_as.h"
         void g(float);
         void f(void){
             g(iasf(0xABCD));
         }
 
 This notation at the use point is not much more clumsy than what Herman
 probably wanted, and is at least meaningful in the language, since care
 was taken to explain to the compiler what was going on.
-- end excerpt from <723522717@sheol.UUCP> -- 

While I'm at it, I'd appreciate any explanation for Herman's
position on "first course" exposure:

-- begin additional excerpt --
 : Possibly the situation would eventually improve if CS students, in their
 : FIRST course, would be placed in situations where their code would crawl
 : unless they did such things.
 
 Why should their FIRST course introduce them to situations
 that are strikingly atypical of most software development?
 Well, Herman's hope is:
 
 : This might cause more language producers and hardware designers to
 : realize that there can be large costs with separate integer and floating
 : registers, and that Boolean operations on floating numbers do make sense. 
 
 It is possible that the cause (ie: early introduction of atypical
 application-specific difficulties) would have this effect (having
 undue attention payed to niche requirements).  It is not clear
 that this is a good thing, however.
-- end additional excerpt --
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.lang.misc