Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Some questions about ANSI C
Message-ID: <6265@brl-smoke.ARPA>
Date: Sun, 9-Aug-87 19:17:04 EDT
Article-I.D.: brl-smok.6265
Posted: Sun Aug  9 19:17:04 1987
Date-Received: Thu, 13-Aug-87 01:31:55 EDT
References: <497@houxs.UUCP> <165600007@uiucdcsb>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 61

In article <165600007@uiucdcsb> kenny@uiucdcsb.cs.uiuc.edu writes:
>>	Library headers must be included only outside of declarations.
>Uh, this wasn't mandated before?  It seems kind of obvious....

Obviously, it must not have been mandated before.
I myself have occasionally #included headers inside function bodies,
when I knew that it would not cause a problem.
(I promise not to do that any more, though!)

>>	Hexadecimal escape sequences \xhhh may contain an arbitrary number
>>	(1 or more) of hex digits.
>Is there some accepted way to announce that a hex escape is at an end?
>For instance, I might want to describe the ASCII sequence ESC 'B' as
>"\x1bB"; will this have to be ("\x1b" "B") as the spec now stands?

Yes, or else you can write it using an octal constant.
This was a compromise to remove an unnecessary restriction with
minimum impact on existing code (which may use octal escapes, but
not hexadecimal, which is a new addition to the language).

>>	Setjmp must be a macro.
>Does this really translate to ``Setjmp need not exist as a library
>function, but may be implemented in macro form only?'' Requiring the
>implementor to include something like
>	extern int _Setjmp_ (jmp_buf);
>	#define	setjmp(jb)	(_Setjmp_((jb)))
>in <setjmp.h> seems just a trifle silly.

I don't have the exact wording that's going into the draft,
but I think the problem is that the argument to setjmp() is being
passed by name, which is possible for macros but not for functions.
(This is based on the traditional implementation of a jmp_buf as an
array, which does not behave the same as other types as a typedef,
coupled with the observation that some implementations would be
better off with a non-array for their jmp_bufs.)

>>	[agreed in principle] that parentheses should force grouping,
>>	motion needed.
>Doing away with unary + once again?  I can live with either solution,
>(although I mildly prefer the unary +) but the waffling on this issue
>is starting to get annoying.

The problem is, the public keep complaining about unary + and/or
the lack of grouping for parens.  I think X3J11 must have decided
that the "as if" rule still permits most ordinary regrouping of
parenthesized expressions even if the spec requires that they
imply execution order.  Perhaps someone who was at the meeting
can explain how the discussion went.

>>	Aliasing restrictions:  An lvalue must match the type of the object
>>	it accesses[,] or the type with or without the unsigned attribute, or
>>	the type of an aggregate that contains the type, or be of a char type.
>	            ^^^^^^^^^^^^ Shouldn't this read ``a union''?

It's possible that other constraints force it to be a union;
I really don't know.  The above wording was taken directly
from the (unofficial) minutes; perhaps it is incorrectly
recorded.  I have a dim recollection that certain allowances
were made for pointers to structs containing a type as their
first member being assignment-compatible with the type, or
something like that.  Perhaps that's what is intended here.