osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (07/30/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Tue, 30 Jul 85 Volume 8 : Issue 17
Today's Topics:
C.3.3.3: unary + vs. unary -
C standard for options
free(), ftruncate()
Support for multiprocessors in C standard (wish)
Typeahead
Words of Wisdom?
----------------------------------------------------------------------
Date: 24 Jul 85 02:19:06 CDT (Wed)
From: ihnp4!utzoo!henry
Subject: C.3.3.3: unary + vs. unary -
To: ihnp4!cbosgd!std-c
> . . .suppose that E is (a + (b + c)). 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. ...
The wording in the discussion of regrouping, in the intro to C.3, is not
100% unambiguous. But the most plausible interpretation of it 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* -- unary minus does not meet the
specs for regroupable operators anyway. 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
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: Wed, 24 Jul 85 17:35:29 PDT
From: "Niket K. Patwardhan" <ucbvax!lcc.niket@UCLA-LOCUS.ARPA>
Subject: C standard for options
To: cbosgd!std-c@BERKELEY
Is the committee considering some standardization of the options? There are
semantics associated with these options that affect the code produced. Eg
-Dxxxxx make xxxxx a defined preprocessor variable
-Ixxxxx xxxxx is a directory in the search list for include files
-O optimize
-c compile but do not remove external symbol table
-o xxxxx Output file is xxxxx
-P Preprocessor pass only.
-E Preprocessor output also goes to stdout
-S Produce assembly language file
Most of these have already become pseudo-standards on UNIX machines, while
some are pseudo-standards across the board. Nailing them down would help
users of the C compilers make effective use of them. Maybe the committee
could consider a "suggestions" section for the standard in which matters
of standardization outside the input file could be discussed. This would
make it easier for a later standards body to actually go and standardize
things.
------------------------------
Date: Fri, 26 Jul 85 01:46:30 PDT
From: sun!guy (Guy Harris)
Subject: free(), ftruncate()
To: std-c@cbosgd
> D.10.3 Clarify that free() must not die if passed NULL since
> {c,m,re}alloc can return such pointers.
Or, alternatively, warn that NULL pointers shouldn't be handed to "free()";
normally, if "{c,m,re}alloc()" returns a NULL pointer, You Have A Problem
and you aren't likely to want to free the block of storage that *alloc has
just told you it couldn't find the memory to give you. It doesn't make much
sense to tell "free()" to free nothing...
> Finally, I cannot belive that the library functions do not include an
> ftruncate() call.
The "ftruncate()" system call (which I agree every UNIX should have) takes a
file descriptor as an argument. None of the UNIX system calls which return
file descriptors are in the standard (at least they're not in my November
1984 draft) - with good reason; this is not a UNIX C standard, it's a C
standard. The proposed C I/O library does, indeed, bear a startling
resemblance to the UNIX Standard I/O library, but there also exist, I
believe, OS and GCOS implementations of that library. "ftruncate()" is an
operating system function, not a C I/O library function, so it belongs in an
operating system standard, not a language standard.
Guy Harris
------------------------------
Date: Wed, 24 Jul 85 16:58:18 PDT
From: "Niket K. Patwardhan" <ucbvax!lcc.niket@UCLA-LOCUS.ARPA>
Subject: Support for multiprocessors in C standard (wish)
To: cbosgd!std-c@BERKELEY
I would like to know if the C standards committee will consider support
for shared memory. Hear me out..............
In every C implementation I know (XENIX286, VAX SYS5, 3B2, M68000)
the statement
int a;
.....
if(a+=1) x;
else y;
is compiled into the equivalent of
ADD 1 to _a
JZ label for y
label for x
What this means is that _a is incremented and the condition code set in an
uninterruptible single instruction. Thus we have all we need for a
synchronization primitive. However because there is no guarantee that this
will in fact happen, I cannot depend on this while writing code, and am forced
to use the semaphores provided by the OS. Usually, all I'm interested in is
updating a single variable in the shared segment in one step, and the cost
of making the OS call could be prohibitive.
What I would like to see is that the standard specify that
the op= operator take place in one step..... or the compiler warns you when
it cannot do so. In addition, the construct
int a;
.....
if (a op= CONST)
should also be implemented in an uninterruptible way.... or warn you if not.
I believe that such a requirement is not just dressing, it could make
the difference between whether C is used for the parallel algorithms now
being implemented, or not. A lot of manufacturers are going to parallel
machines - in the sense of multiple microprocessors - and will need a decent
system language. In a sense their problem is harder, even single instructions
could have another operation on the same memory location take place between
the fetch and store. It may even be worthwhile to recommend that such an
operator (atomic test and set) be explicitly defined and included. (unary ^ ?)
------------------------------
Date: Fri, 26 Jul 85 11:47:04 edt
From: zinfandel!berry
Subject: Typeahead
To: std-c@cbosgd.UUCP
In article <618@hou2d.UUCP> Michael Gersten <packard!UCLA-LOCUS.ARPA!cc1> writes:
>B.1.2.3 All output directed to interactive devices must occur before new
>interactivly generated input is accepted
>
>Does this mean typeahead is illegal?
Not as I read it -- it means that pending output must be flushed out
before pending input is READ by the program.
--
Berry Kercheval Zehntel Inc. (ihnp4!zehntel!zinfandel!berry)
(415)932-6900 (kerch@lll-tis.ARPA)
------------------------------
Date: Thu, 18 Jul 85 20:32:46 edt
From: Chris Torek <seismo!maryland.ARPA!chris>
Subject: Words of Wisdom?
To: cbosgd!std-c@maryland.ARPA
The following is an excerpt from a reply to a letter in the July
1985 _Communications of the ACM_. The reply is by David L. Parnas
and is in regard to some criticisms about Ada; however, I believe
they are also relevant to the C standardization effort. (The ACM
copyright notice indicates that "Copying without fee is permitted
provided that copies are not made or distributed for direct commercial
advantage and credit to the source is given. Abstracting with
credit is permitted.")
``In addition to the technical problems with the Ada language,
there is a common sense rule that has been violated by its
developers; one should not standardize and innovate simultaneously.
Both standardization and innovation are `good things'---in their
place. When innovating, one must allow time for experimental
evaluation and correction. When choosing a standard, one must
take something whose utility has been proven in practice.''
I believe that the ANSI X3J11 committee should consider this
carefully with regard to such things as ``void *'', ``const'',
parameter prototypes, and union initialization. (This is not to
be taken as a statement against the proposed mechanisms.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland
------------------------------
End of mod.std.c Digest - Tue, 30 Jul 85 08:30: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.