[mod.std.c] mod.std.c Digest V8#14

osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (07/19/85)

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


mod.std.c Digest            Thu, 18 Jul 85       Volume 8 : Issue  14 

Today's Topics:
                            flag to fopen
                   Linkage of identifiers (C.1.2.2)
                         name space of labels
     Section C.3.15 Conditional operator (Mark Purtill's remarks)
----------------------------------------------------------------------

Date: 14 Jul 85 14:39:24 N (Sun)
From: seismo!mcvax!guido
Subject: flag to fopen
To: std-c@cbosgd

>From: decvax!minow (Martin Minow)
>Subject: flag to fopen
>
>rb	open binary file for reading [also wb, ab]
>r+	open text file for update [also w+, a+]
>r+b	open binary file for update [also w+b, a+b]

Is there a prescribed ordering for the second and further flag characters?
I know of at least one implementation which uses "rb+" instead of "r+b".
Perhaps the implementation could be required to accept these flags
(and any other it defines itself) in any order.
(I *do* see why "r+b" is more logical than "rb+" -- the + depends on the
structure of the application, while the necessity of the b depends on
peculiarities of the implementation.)

	Guido van Rossum, CWI, Amsterdam.  guido@mcvax.UUCP

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

Date: Wed, 17 Jul 85 14:49:38 +0200
From: seismo!mcvax!jack (Jack Jansen)
Subject: Linkage of identifiers (C.1.2.2)
To: std-c@cbosgd

If I understand this paragraph correct, it says some very funny things:

"If the declaration of a function or object contains the keyword
extern, the identifier has the same linkage as any previous
declaration of the identifier with file scope. If there is no
previous declaration with file scope, the identifier has external
linkage".

Does this mean that the declarations
static int foo;
extern int foo;
are correct? *If* they are, I would assume that the 'extern' would
get precedence (I believe that that is also the case in many current
implementations).

Also:
"If an identifier declared with external linkage is used in an expression,
somewhere in the entire program there must be exactly one *external
definition* for the identifier (a declaration that has external linkage
and for which storage is allocated). If an identifier declared with
external linkage is not used in an expression, there need be no
definition for it."
(Emphasis in the original)
Does this mean that 
extern int foobie;
should not produce an error if foobie isn't defined, as long as
you don't use foobie?
This is probably a feature that will make many implementations more
difficult (notably for the NS32000, which uses a 'linkage table',
through which all externals are imported/exported), while not
providing much gain.
--
	Jack Jansen, jack@mcvax.UUCP
	The shell is my oyster.

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

Date: Sun, 14 Jul 85 20:53:12 edt
From: John White <mcnc!jnw>
Subject: name space of labels
To: std-c@cbosgd

     Section C.1.2.3 of the April revision requires "ordinary" identifiers
to be in a different space from label names. This means that an identifier
can be defined as a variable and a label in the same scope with the compiler
using context to disambiguate. ("a" is a variable in "a=b;" and a label
in "a:".)
     The standard should not require the use of separate name spaces for
variables and labels. No compiler that I have tried supports this. Also,
depending on how a compiler is implemented, it could be very difficult to
add. If a compiler looks up an identifier in a table before the next token
is read in, then the compiler cannot distinguish between "a=b;" and "a:".
In the other cases where separate spaces for identifiers are required, the
compiler can use PRIOR context, but with variables and labels the compiler
must read the next token before an identifier can be converted to a token.
- John N. White <mcnc!jnw>

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

Date: Wed, 17 Jul 85 08:35:49 -0100
From: Andrew Macpherson <garfield!mcvax!stc!andrew>
Subject: Section C.3.15 Conditional operator (Mark Purtill's remarks)
To: std-c@cbosgd

Mark Purtill wrote:
> Section C.3.15 Conditional operator

> >Syntax
> > conditional-expression:
> >     logical-OR-expression
> >     logical-OR-expression ? logical-OR-expression : conditional-expression
> This allows a?b:c?d:e but not a?b?c:d:e, which seems strange, especially
> as I prefer the second.  (The first could be read as (a?b:c)?d:e, but
> the second is unambiguous).  I suggest changing the last line to
>       logical-OR-expression ? conditional-expression : conditional-expression

I have long felt this change ( from a right-associative as defined
in K&R, to a left associative operator) to be overdue.  Strangely the
change will not break existing code, since at present Mark's second
example, which uses more conventional "if-else" binding would have to
be bracketed thus:  a?(b?c:d):e

It would of course break existing compilers.

I also have slight reservations at the prospect of:

	rval = a ? b ? d	/*
		     : e	 * Indented for ( I hope )
		 : c ? f	 * clarity
		     : g;	 */

Since it would inevitably appear as:

	rval = a ? b ? d : e : c ? f : g;

Which is the sort of thing the denigrators of c are so keen to pounce upon.
-- 
Regards,
	Andrew Macpherson.	<andrew@stc.UUCP>
	{creed, datlog, idec, iclbra, iclkid, root44, stl, ukc}!stc!andrew

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

End of mod.std.c Digest - Thu, 18 Jul 85 17:00:41 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.