mod.std.c Digest V9#1

[Orlando Sotomayor-Diaz]

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


mod.std.c Digest            Thu,  1 Aug 85       Volume 9 : Issue   1 

Today's Topics:
        Atomic operations in the C language - there's no hope
                           free((void *) 0)
                       unary +/- and regrouping
----------------------------------------------------------------------

Date: Thu, 1 Aug 85 02:30:28 edt
From: "John R. Levine, P.O.Box 349, Cambridge MA 02238-0349 (617-494-1400)" <johnl at ima.UUCP>
Subject: Atomic operations in the C language - there's no hope
To: std-c at cbosgd

A letter in V8 #17 suggests that it would be nice if the standard could 
guarantee that operations like a += 1 be atomic.  Such an idea seems to me to 
be misguided.  For one thing, many machines such as the IBM 360 series have no 
add-to-memory instructions, so they can't do it.  Furthermore, different 
machines have different low level approaches to locking.  Some, as noted, have 
regular instructions that atomically modify memory.  Others have a conditional 
exchange instruction, an unconditional exchange instruction, or even in some 
cases a locking prefix that tells the cpu to execute the following instruction 
atomically.  

You can write all sorts of swell concurrent stuff in C, and the "volatile" 
keyword is an important feature for doing such stuff.  But the right place for 
synchronization operators is in libraries.  This needn't be impossibly slow - 
every Unix kernel is really a concurrent C program and some of them perform 
pretty well.  Some of them even do so while running on many processors.  

This could be an interesting topic for further discussion but not, I think, in 
std-c.  Feel free to send me mail.  

John Levine, ima!johnl Levine at YALE.ARPA

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

Date: Wed, 31 Jul 85 13:07:53 EDT
From: ihnp4!seismo!elsie!ado
Subject: free((void *) 0)
To: hou2d!osd

> D.10.3 Clarify that free() must not die if passed NULL since
> {c,m,re}alloc can return such pointers.

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.
--
	UUCP: ..decvax!seismo!elsie!ado    ARPA: elsie!ado at seismo.ARPA
	DEC, VAX and Elsie are Digital Equipment and Borden trademarks

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

Date: Thu, 1 Aug 85 01:55:06 EDT
From: ihnp4!seismo!elsie!ado
Subject: unary +/- and regrouping
To: hou2d!osd

> > . . .If I understand alright, if I write
> > 	(0-(a + (b + c))
> > then this may be (regroupedly) computed as
> > 	(0-((a + b) + c))
> > whereas if I write
> > 	-(a + (b + c))
> > such a regrouping is not allowed. . .
>				elsie!ado

> . . .the most plausible interpretation. . .is that the
> unary + or - only causes the parentheses that it immediately precedes to
> be taken as inviolate -- this effect does not propagate inward.  So the
> compiler may not turn "z + +(a + (b + c))" into "(z + a) + (b + c)", but
> may turn it into "z + +((a + b) + c)".
> I use + in my example because it's not obvious just what the inhibition
> of regrouping by unary minus *means*. . .I think the ultimate moral of
> the story is the regrouping discussion in the C.3 intro needs rewording
> for clarity.
>				 Henry Spencer @ U of Toronto Zoology

I agree with the suggestion about rewording; I'll try rewording C.3.3.3 below.

First, though, as to what inhibition of regrouping by unary minus means--
perhaps it is that while
	a - (b + c)
may be computed as
	(a - b) - c
you can inhibit this by writing
	a + -(b + c)

As for rewriting, I think changing
	Except that it inhibits regrouping, the expression +E is equivalent to
	(0+E).
to read
	Except that it inhibits regrouping involving subexpressions of E,
	the expression +E is equivalent to (0+E).
gets across my notion of what unary + is supposed to do, while
	Except that it inhibits regrouping of subexpressions of E with
	subexpressions outside of E, the expression +E is equivalent to (0+E).
gets across Henry Spencer's notion.
--
	UUCP: ..decvax!seismo!elsie!ado    ARPA: elsie!ado at seismo.ARPA
	DEC, VAX and Elsie are Digital Equipment and Borden trademarks

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

End of mod.std.c Digest - Thu,  1 Aug 85 21:11:47 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.