Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-hermes!iuvax!pur-ee!uiucdcs!uiucdcsb!kenny
From: kenny@uiucdcsb.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Some questions about ANSI C
Message-ID: <165600008@uiucdcsb>
Date: Thu, 13-Aug-87 02:37:00 EDT
Article-I.D.: uiucdcsb.165600008
Posted: Thu Aug 13 02:37:00 1987
Date-Received: Sat, 15-Aug-87 07:51:00 EDT
References: <497@houxs.UUCP>
Lines: 62
Nf-ID: #R:houxs.UUCP:497:uiucdcsb:165600008:000:3108
Nf-From: uiucdcsb.cs.uiuc.edu!kenny    Aug 13 01:37:00 1987


Doug Gwyn, describing Paris conference results (DG>) and me, asking
stupid questions (KK>):

DG>Setjmp must be a macro.

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

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

Gosh, how did I miss that?  I must be getting really sloppy in my old
age (after all, I remember when structs were passed by reference,
too... 8-) ).

Isn't the problem really that setjmp accepts a jmp_buf rather than a
jmp_buf *?  (Ditto longjmp, I suppose, although it's less obvious that
a value parameter couldn't be used).  It seems that perhaps the spec
should simply be altered to change the data type.  It would cause
existing code to lint incorrectly, but otherwise would, as far as I
know, not break anything; it's hard to imagine an implementation so
perverse that it doesn't use the same representation for ``foo (*)[]''
as it does for ``foo *''.

I will concede that the ice is thin here, but we otherwise condemn
future generations of C programmers to learning that all library
function parameters are passed by value, oh yes, except for setjmp,
which is REALLY a macro that coerces its parameter to being passed by
name, oh yes, which means that its parameter must be an lvalue, not an
rvalue like those of all other functions.

Any comments, from either Doug or the peanut gallery?

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

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

I get the idea.  Perhaps instead of ``an aggregate that contains the
type'' we should say ``a union that contains the type, or a structure
having the type as its first member,'' and then also expand the
verbiage that any of *those* may in turn have the unsigned attribute
added or removed.  (There has got to be a cleaner way to express this.
But it's 1:30 in the morning and I'm only half sentient.)