osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (08/17/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c> mod.std.c Digest Sat, 17 Aug 85 Volume 9 : Issue 4 Today's Topics: C.1.2.5 Types free((void *) 0) Indivisibility more comments V9#2 modf, longjmp comments ---------------------------------------------------------------------- Date: Thu, 8 Aug 85 03:37:41 edt From: hcr!lsuc!msb Subject: C.1.2.5 Types To: hcr!cbosgd!std-c Henry Spencer replies to an item of mine thus: > If you look carefully, you will see that enums are *not* a primitive type; > they are a way of giving names to integer constants. ... I wasn't suggesting that enums should be a primitive type. I was suggesting that they should not be considered derived types, unless void is also to be considered a derived type. I think there should be three types of types: primitive, enumeration (enum, void), and derived. Primitive types take on "all values such that such-and-such"; enumeration types take on "the following values"; derived types are combinations and variations (pointer, function returning, ...) of other types. This is only a matter of terminology, of course. Mark Brader ------------------------------ Date: 9 Aug 85 16:49:26 CDT (Fri) From: ihnp4!hpfcla!hpfclo!jad Subject: free((void *) 0) To: hpfcla!cbosgd!std-c > Date: Wed, 31 Jul 85 13:07:53 EDT > From: ihnp4!seismo!elsie!ado > > Many (most?) existing systems die if free is passed NULL. > So let's mandate that free() MUST DIE if passed NULL. > This will discourage folks from passing NULL to free, > and will therefore encourage the development of more portable code. I disagree with this on basic principles. You should not design things to die when presented illegal input that you know about. free() should just return gracefully, after doing nothing. If passed a pointer to memory that has been free()d already, then the core dump is acceptable, but I'd rather see it return (-1). In general, don't make it easier for the user to dump core!! Discourage unportable code using other methods. -- jad -- John A. Dilley, FSD Fort Collins, CO ARPA: terrapin@Purdue.EDU UUCP: {ihnp4}! hpfcla!jad PHONE: (303)226-3800 x4166 ------------------------------ Date: Fri, 16 Aug 85 15:00:47 pdt From: Vincent Manis <manis%ubc.csnet@csnet-relay.arpa> Subject: Indivisibility To: std-c@cbosgd I hate to find myself in the position of defending the 370 architecture, but you can indeed guarantee indivisibility. Just simply surround your code with TS (test and set) instructions--that's how the operating system does it. The question of the advisability of indivisible operations is really not one of feasability--every processor has some means of serialising instructions (the TI 990 series does it with the ABS instruction!). Rather, if one requires such an evaluation order, a conforming implementation has to generate worst-case code in *every* program. Even if every machine known had indivisible add/subtract to memory instructions, putting such a requirement in the standard would enforce this on future machines. Now, why is this indivisibility wanted? Is it to facilitate parallel programming? Not really: as has been pointed out, you can write parallel code in C as is (most readers of this newsgroup probably do it quite often). Rather, the suggestion is intended to simplify implementation of a synchronisation kernel. At the risk of sounding like a fuddy-duddy, I must say that such a kernel is one of the few pieces of code which *should* be written in machine language: it absolutely has to be correct, and system efficiency depends upon it critically; not only that, it's generally small (a few hundred lines). Long live indeterminacy! ------------------------------ Date: Mon, 12 Aug 85 18:47:11 MDT From: utah-cs!utah-gr!thomas@utah-gr.UTAH-CS (Spencer W. Thomas) Subject: more comments To: std-c@cbosgd In article <625@hou2d.UUCP Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA> writes: >The & (address-of) operator needs to have some constraints put on it's >argument. As the standard currently reads "&2" is legal. So is "&++a". >And lots of other bad stuff. I think you are confusing syntax with semantics. You can write a lot of things that are syntactically correct but are semantically incorrect (like using undeclared variables). You can't enforce everything in the syntactical analysis stage. (Now, this is not to say that you may be able to restrict it further.) >section D.5.4.6 > >int modf( double value, double *intptr) ; /* return fractional part of value */ > /*and puts the int part in *intptr */ >"modf" is a horrible name. an extract from our Unix manual: NAME frexp, ldexp, modf - split into mantissa and exponent ... double modf(value, iptr) double value, *iptr; =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) ------------------------------ Date: Wed, 14 Aug 85 00:40:03 cdt From: ut-sally!cyb-eng!howard@ihnp4.uucp Subject: V9#2 modf, longjmp comments > int modf(double value, double *intptr); /* return fractional part of value */ > /*and puts the int part in *intptr */ > "modf" is a horrible name. Or maybe ... I've confused ... > [modf with something else.] Modf has been around for a long time. I suspect it would be more work to require everyone to change their existing source code. Let's not repeat the mistake that the System V authors made by renaming index(), et al. to strchr() and friends. > ... and if the intptr argument is absent or NULL don't bother with > the int part. Sounds ok to me. > Is there a good reason why you can't let longjmp have setjmp return 0? Perhaps you'd rather that longjmp() call abort() or some such thing if longjmp is passed a 0 to return. Allowing longjmp to return zero seems to defeat the purpose of setjmp/longjmp. I agree that something might potentially be done with what you suggest, but why encourage the obtuse? ------------------------------ End of mod.std.c Digest - Sat, 17 Aug 85 13:28:08 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.