mod.std.c Digest V9#4

[Orlando Sotomayor-Diaz]

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 at 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 at csnet-relay.arpa>
Subject: Indivisibility
To: std-c at 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 at utah-gr.UTAH-CS (Spencer W. Thomas)
Subject: more comments
To: std-c at cbosgd

In article <625 at hou2d.UUCP Mark Purtill <ucbvax!Purtill at 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 at utah-cs.ARPA)

------------------------------

Date: Wed, 14 Aug 85 00:40:03 cdt
From: ut-sally!cyb-eng!howard at 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 at BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.