Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!ames!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <29572@news.Think.COM>
Date: 16 Sep 89 20:47:44 GMT
References: <246@ssp1.idca.tds.philips.nl> <225800221@uxe.cso.uiuc.edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 66

In article <225800221@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>But somewhere there has to be a way to diddle the bits in objects
>that are not integers (where of course there are the legal & and |
>operators. Somebody, somewhere has to be able to diddle the bits
>in a double or float, in order to construct it out of an integer
>
>double d; int i;   ......      d = i;

Many machines with floating point hardware have instructions that do
such conversions.  No one has to "diddle the bits".

>and somebody has to diddle the bits in a pointer (on machines with
>segments or read-write-execute bits stuck onto pointers) when it
>is created (by malloc or the OS).

In some architectures, the bits of a pointer may only be diddled by
privileged instructions.  User code can only create pointers by
modifying existing pointers (e.g. adding offsets).  Pointers are
created by performing system calls to allocate new segments, for
instance.

>One can diddle bits in pointers by using integer types and then
>casting to pointers, but doing it in float types requires unions -
>because casting an integer type to a float type preserves the VALUE,
>not the bits.

Where is it written that casting between pointers and integers
preserves the bits?  I think that under the Symbolics C compiler, the
result of any cast from integer to pointer is a null pointer.  The
pANS says that the result of such a cast is implementation-dependent,
so this is OK.  Since Symbolics C pointers aren't memory addresses
(they are a pair of a array (whose address could change due to garbage
collection) and an index), a value-preserving cast between integers
and pointers would be prohibitively expensive.

> Why would someone want to construct a float themselves,
>rather than casting?  Well, perhaps they desire to construct
>an illegal value (i.e. IEEE float format NaN). This might occur
>inside a floating exception handler, or a math routine ( sqrt(-6) ).
>Perhaps some might say "do it in assembler", but 
>sometimes I would like to do it in C.  When I say "somebody" I am
>including explicitly the routines in the OS that pass pointers
>to "malloc".

Any code that diddles bits in the representation of an object is by
definition not portable, so what does it matter what the standard
says?  If the hardware allows it, then you can probably get the C
implementation for that hardware to do it.  But since not all
hardwares permit such operations, it would be a mistake for the C
standard to mandate a way to do it.

>Is not most of Unix written in C?  Doesn't this sort of stuff
>happen there?

There are a few system-dependent modules in the Unix kernel.  There's
even some assembly code in there in most implementations.  For
instance, the kernel must change interrupt priority levels at times,
but there's no standard C syntax for this.  Are you proposing that
there be a standard C syntax for everything that any machine can do?
ANSI C isn't intended to be a replacement for assembly language.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar