Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC830713); site edai.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!ukc!edcaad!edee!edai!ok
From: ok@edai.UUCP (Richard O'Keefe)
Newsgroups: net.lang.c
Subject: typeof
Message-ID: <4440@edai.UUCP>
Date: Tue, 24-Jul-84 07:50:38 EDT
Article-I.D.: edai.4440
Posted: Tue Jul 24 07:50:38 1984
Date-Received: Sat, 21-Jul-84 02:37:06 EDT
Organization: Art.Intelligence,Edin.Univ.
Lines: 53


     I know the C standards group are trying to minimise changes
to the language, but there is one change which shouldn't do much
harm and would help people writing macros.  Let

	typeof <thing>

(where <thing> is whatever sizeof <thing> would allow) be used
as a type specifier.  Why would this be useful?  So that people
could define macros like

#define swap(x,y) {typeof x  *ZQ1 = &(x), *ZQ2 = &(y), t;\
		   t = *ZQ1, *ZQ1 = *ZQ2, *ZQ2 = t;}
/*  If there is a better way of defining this to work when
    x and y may contain arbitrary side-effective expressions
    I'd like to know it.
*/
#define SetNull(x) x = (typeof x)(0)

     The definition should explicitly say that the <thing> is
NOT evaluated (otherwise "swap" won't work).

     Someone said that the standard allows white space before a
sharp.  I hope this was a misunderstanding, and that explicitly
allowing white space after a sharp was meant.  Till now people
have been able to use " #" for tools that manipulate C code,
secure in the knowledge that C can't use sharps anywhere, and
the preprocessor can only see them in the first column.  (E.g.
there is a tool that lets you write end-of-line comments like
Ratfor instead of ugly /**/ filth.)  This change would break
those tools.  I can't see what the change is FOR; if you're
worried about the indentation you can leave the sharp at the
left margin and indent the keyword.

     Re the use of
#define	QUOTE(X) X
#define CONCAT(x,y) QUOTE(x)y
it was my understanding that the preprocessor was entitled to
include the newline (or a corresponding space) that ended the
definition of QUOTE in its expansion, so might not CONCAT(a,b)
expand to "a b"? The ONLY satisfactory answer to this problem is
for some public-spirited hero to write a public domain C
preprocessor in (sub-)standard C and send it to net.sources.
I'd do it myself, but I haven't got the time right now.

     This business of 6 letter external names, I don't
understand it.  COBOL has had 30-character names for YEARS, and
several COBOL compilers have a form of separate compilation.  If
a linker or object module format can handle 30-character
monocase names with hyphens, it can handle 30-character monocase
names with underscores (mapped to hyphens).  I suppose we should
be grateful that no-one is worried about IBM 1130 compatibility
or we'd have 5 letter external names!