mod.std.c Digest V9#1
Orlando Sotomayor-Diaz
osd at hou2d.UUCP
Fri Aug 2 11:14:49 AEST 1985
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.
More information about the Mod.std.c
mailing list