Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83 based; site hou2d.UUCP Path: utzoo!decvax!bellcore!petrus!sabre!zeta!epsilon!gamma!ulysses!mhuxr!mhuxt!houxm!hou2d!osd From: osd@hou2d.UUCP (Orlando Sotomayor-Diaz) Newsgroups: mod.std.c Subject: mod.std.c Digest V10#2 Message-ID: <689@hou2d.UUCP> Date: Tue, 17-Sep-85 07:19:07 EDT Article-I.D.: hou2d.689 Posted: Tue Sep 17 07:19:07 1985 Date-Received: Wed, 18-Sep-85 01:20:09 EDT Organization: AT&T Bell Labs, Holmdel NJ Lines: 149 Approved: osd@hou2d.UUCP From: Orlando Sotomayor-Diaz (The Moderator) 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 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 Subject: Realloc - portability To: std-c@cbosgd Alain Williams 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. {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. Brought to you by Super Global Mega Corp .com