pcg@aber-cs.UUCP (Piercarlo Grandi) (11/24/88)
In article <1988Nov22.170953.24489@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: In article <122@halcdc.UUCP> randy@halcdc.UUCP (randy orrison) writes: >|>Two problems: the space after gets would kill it if it's a macro, >| >|Say WHAT? Works fine on all the compilers I know of. "Preprocessor" >|macros don't require that you give the exact same amount of white space >|in the invocation as you gave in the definition... Definitions of parameterized macros ("function-like" macros in X3J11speak) have always been required to have the "(" immediately following the identifier. The May draft standard requires that in the invocation, the "(" must be "the next preprocessor token", which basically means that white space there is okay. Now I have always had a low opinion of the X3J11 work (e.g. not to realize that unsigned and int are different types, as they obey different rules for arithmetic, and char short and long are just range/length modifiers, and not the other way round), but this last idea really leaves me gasping... Obviously there must me a way to distinguish between macro bodies that begin with a "(" and macro definitions with a parameter list, is there one ? I mean one that is not a trick like defining a null token BODY or putting a null comment before the "(" that starts the body, and one that does not break all the existing macro definitions that whether with parameters or not you had better enclose in parenthesis... -- Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)
henry@utzoo.uucp (Henry Spencer) (11/27/88)
In article <264@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >> Definitions of parameterized macros ("function-like" macros in >> X3J11speak) have always been required to have the "(" immediately >> following the identifier. The May draft standard requires that in >> the invocation, the "(" must be "the next preprocessor token", >> which basically means that white space there is okay. > >...Obviously there must me a way to distinguish between macro bodies that >begin with a "(" and macro definitions with a parameter list, is there >one ? Please re-read what I said; the *definition* of a macro and an *invocation* of said macro are entirely different things. -- Sendmail is a bug, | Henry Spencer at U of Toronto Zoology not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bill@twwells.uucp (T. William Wells) (11/27/88)
In article <264@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
: Now I have always had a low opinion of the X3J11 work (e.g. not to
: realize that unsigned and int are different types, as they obey
: different rules for arithmetic, and char short and long are just
: range/length modifiers, and not the other way round), but this last
: idea really leaves me gasping...
:
: Obviously there must me a way to distinguish between macro bodies that
: begin with a "(" and macro definitions with a parameter list, is there
: one ?
Judging by this evidence, your opinion of X3J11 is based on
misinformation.
Firstly, they do indeed have unsigned and ints as different types.
(And I can't figure out whatever you meant by `char short', etc. but
they haven't really changed anything there either.)
Secondly, they have done nothing to change the way that parentheses
are used when defining a macro. A macro with arguments gets defined
with:
#define <name>(<argument>) <body>
where either <argument> or <body> may be null. White space must not
appear between the <name> and the open parenthesis. A macro with no
arguments get defined with:
#define <name> <body>
and there must be white space between <name> and <body>.
---
Bill
{uunet|novavax}!proxftl!twwells!billpcg@aber-cs.UUCP (Piercarlo Grandi) (11/29/88)
In article <1988Nov27.010155.29222@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
Please re-read what I said; the *definition* of a macro and an *invocation*
of said macro are entirely different things.
--
Sendmail is a bug, | Henry Spencer at U of Toronto Zoology
not a feature. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
Ok, ok! I just happened to misread, and I read *definition* in both
places; you know, when dpANS is involved my subconscious plays some
tricks, and I can believe whatever ridiculous thing it puts before my
eyes. Yes, I am prejudiced, and I am not proud of it, but I like to
have some prejudice here and there.
I can only offer one of these explanations for it:
I had eaten too many pork scratchings.
I had read too many ramblings on the worm debacle in tcp-ip.
An alpha particle hit several cones in my retina.
The random gaffe generator function of rn had hit me.
....
Whatever the reason, I should have paid more attention; I was really
taken away by my prejudices, and my most abject apologies for this to
all of you.
On the other hand (and in order to sidetrack an embarassing
discussion), I still don't like the introduction of signed as an
alternative to unsigned as attributes for types char,short,int,long,
instead of interpreting char,short,long as attributes of types
unsigned,int. Any reasonable reason :-) to eschew the latter solution?
(and no, I will not even mention my HATE for volatile, far, near and
the repeated attempts to get noalias in the language, which things in
my skewed mind overshadow whatever contribution dpANS has made to
clarify so many other issues).
--
Piercarlo "Peter" Grandi INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/01/88)
In article <283@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >(and no, I will not even mention my HATE for volatile, far, near and >the repeated attempts to get noalias in the language, which things in >my skewed mind overshadow whatever contribution dpANS has made to >clarify so many other issues). You really ought to investigate your sources of information! The dpANS has never, to my knowledge, proposed that "far" and "near" keywords be added to C. In fact they are prohibited in a standard-conforming implementation. There have not been "repeated attempts to get noalias in the language". Since you seem to have missed the excitement, here is a brief summary of what happened concerning "noalias": There were two opposing camps concerning what the meaning of the "const" type qualifier should be. One of them, which prevailed when "const" was added to the dpANS, wanted it to be compatible with C++ "const", namely to act as a "readonly" indicator. The other camp wanted it to promise something about how a so-designated variable could validly be accessed, so that optimizers could take advantage of a "const" qualifier to provide improved optimation. In evening working sessions preceding preparation of the second formal public review dpANS, the opposing camps explored these issues and found that the aliasing aspect really could and should be separated from the readonly aspect. Thus, leaving "const" meaning essentially "readonly" and introducing a new, orthogonal "noalias" qualifier would permit programmers to accurately specify either meaning, which was considered a good solution for this issue. Therefore the new "noalias" qualifier (meaning essentially, "this object is guaranteed not to be accessed via multiple handles") was added for the second formal public review dpANS. Unfortunately, the whole area of type qualifiers had not been worded quite right in the second formal review draft. Dennis Ritchie in particular complained about the consequent pervasive effect that "noalias" would have on library functions, etc. This probably could have been fixed up to specify what was really intended in the first place, but such a big stink was made about addition of a new keyword at such a late date that it was not politically possible to salvage it. As a result, the committee withdrew "noalias" between the second and third formal public review drafts. We also have cleaned up the type qualifier specification so that it should now reflect the committee intention much better than it did in the second round. The one sad thing is that there is now no way to make the kind of promise that the optimizers needed for non-aliased objects. This reflects existing C practice, but it is unfortunate that an improvement in this area wasn't achieved. So, "noalias" was in the dpANS for ONE draft, it was an attempt to solve a real performance problem, it would have been transparent to existing code, and it was promptly removed when the reviewers responded negatively to it. That is hardly an evil plot on the part of X3J11. "volatile" also serves a need. In fact, it directly addresses one of the comments I saw earlier today in this newsgroup, about use of C for accessing device registers. Again, it is transparent to virtually all existing code, it addresses a real need, and it can be ignored by anyone who does not specifically need it. What is your objection to it?