osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (09/17/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Tue, 17 Sep 85 Volume 10 : Issue 2
Today's Topics:
Floating vs. double
free and checking for bad values
Realloc - portability
----------------------------------------------------------------------
Date: Sat, 14 Sep 85 11:05:44 edt
From: allegra!phri!roy (Roy Smith)
Subject: Floating vs. double
To: allegra!cbosgd!std-c
Subject: Re: Can C default to float? Are there float regs?
[from a discussion in net.lang.c]
dove@mit-bug.UUCP (Web Dove) says in article <175@mit-bug.UUCP>:
> Many people in our group find it frustrating that C converts floating
> arithmetic to double. [...] our machines (vax 750/4.2bsd) would be
> faster if the computations were done in straight float.
>
> I realize that this violates the standard for C, but has anyone ever
> changed the compiler to accomplish this?
On a pdp-11, it was reasonable to do all floating calculations
double because of the way the FPP worked. To make it a requirement of the
language is (I think) a serious mistake. If it's not too late, I vote for
making it legal for an implementation to do all floating arithmetic double
precision if there is a serious architectural reason for doing so but not
requiring it (and in fact, discouraging it).
I can't think of any existing code which would be broken by this
change (that doesn't mean none exists). Argument passing might cause some
problems, and two versions of each math library routine would have to be
supplied, but the gain in speed would be substantial. There are many
problems where you want it done fast and don't care about the extra digits
of precision.
Unix, from its earliest days, has been strong on text processing
but weak on number crunching -- the cavalier attitude taken by most C
implementations with floating point reflects this unfortunate trend. If
the language standard demands that you not use single precision even if you
want to, that makes the language a big looser for number crunching right
off and I can understand implementors not wasting time on the rest of the
floating point stuff.
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
Date: Tue, 10 Sep 85 15:11:45 edt
From: mark@cbosgd.ATT.UUCP (Mark Horton)
Subject: free and checking for bad values
To: std-c@cbosgd.UUCP
> Can't you have some external flag (say, _Free_Widget) controlling
>what free does in this situation? It's initialized to 1 in free.c; when
>free() gets an invalid pointer, it looks at the value in _Free_Widget. If
>it is still 1, free() dumps core. If the user has reset it, free() just
>returns some error status.
I'd be very interested to see an acceptably efficient implementation of this.
Just how do you tell that a pointer you've been passed is invalid?
There are some cases you can immediately recognize as invalid. NULL is
obviously illegal. Anything lower than the base of the arena or higher
than the top is illegal (assuming the implementation uses a single
arena, which isn't really a fair assumption to make, but we're trying to
implement this for an easy case first.)
Now, what do you do if the value is inside the bounds of the arena?
Suppose it's a pointer into the middle of a data block somewhere.
There might be arbitrary data there, so you can't check the area
pointed at (or anything relative to it) to make sure the data looks OK.
So your only alternative is to run through the arena from the beginning
to make sure this is a valid block in the chain. (Perhaps a different
implementation would not chain everything together, but that's another
implementation of malloc.)
Now, suppose the user has stepped on the arena due an off-by-one
subscript, clobbering the linkage information. The best you're
going to get is an assertion error or a "corrupt arena", and if
the assertions are compiled out, you'll get a core dump or other
crazy behavior.
Finally, consider what happens when you pass free a pointer to an
area which is valid but has already been freed. There are lots
of interesting possibilities where the area has since been reallocated.
Many of these possibilities suggest that attempts to use the pointers
in question will do bizarre things, often dumping core.
A totally secure implementation of C with lots of runtime support
which insures that no memory can be stepped on without an error
message first might be able to afford such extensive checking.
But the normal C runtime environment can't easily tell if a pointer
is a valid one.
Mark
------------------------------
Date: Mon, 9 Sep 85 09:28:08 -0100
From: Dave Shimell <seismo!mcvax!stc!shimell>
Subject: Realloc - portability
To: std-c@cbosgd
Alain Williams <addw@root44> writes:
>This relates to something that I seem to remember seeing in a proposed
>standard: realloc() is NOT guaranteed to preserve the contents of the area
>that you give it. What is the point of realloc() if it doesn't do this?
>Is my memory at fault, or is this another case of the 'standard being a
>catalogue of the bugs in current implementations'?
I would imagine that the standard you read is merely stating
what is currently the case:
p = realloc(ptr, size);
where p != ptr, in some cases
More verbosely, if the size of the reallocated area increases,
one would expect a new area to be allocated (p != ptr).
Conversely, if the size of the reallocated area decreases, one
would expect the same area to be returned (p == ptr).
However, this is NOT the case on all systems. IS/1 (V6/PWB)
conforms to the above. Ultrix (4.2 derivative) ALWAYS allocates
a new area even if the size decreases.
Moral: assume p != ptr for all realloc() calls.
Regards,
Dave Shimell. <shimell@stc.UUCP>
{root44, ukc, datlog, idec, stl, creed, iclbra, iclkid}!stc!shimell
------------------------------
End of mod.std.c Digest - Tue, 17 Sep 85 07:12:49 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.