"Paul Mensonides" <pmenso57@attbi.com> wrote
> The problem, specifically, is that C99 allows
> nothing to be passed as a macro parameter.

I'm not an expert on C99... are you saying that it allows a macro defined
like this:
    #define MYMACRO abc
to be called like this:
    MYMACRO()
...in other words, it would swallow the following ()?

If that's true, it's going to break code like this:
    #define abc def
    void abc() { printf("hello!\n"); }
...which previously would have defined function def. If macro abc
now "eats" the (), the result is going to be a syntax error!

> This makes it impossible (as far as I can tell) to determine the
> difference between one or zero arguments.  The presence of commas allow
> the detection of everything else:
>
> X() // zero or one parameter?
>
> -vs.-
>
> X(,) // two parameters

Previously, I would have explained it this way:
    X              // zero parameters
    X()            // one parameter
    X(,)           // two parameters...
Now I just don't know anymore...

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
> ... are you saying that ...

No.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Zack Weinberg wrote:
> I believe he said that all the implementations he has tested do exactly
> this?

No, as you said, many issue a warning, which would have to be changed.
Also I suspect there is at least one implementation somewhere that
does reject the translation unit, and it might not be easy to change
it to re-tokenize at a stage where it never had to before.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> >That would certainly impact all conforming C implementations and
> >possibly existing conforming (albeit not strictly conforming) programs.
>
> I believe he said that all the implementations he has tested do exactly
> this?  Really, speaking as an implementor, there are only three
> plausible choices for this situation - silently retokenize, retokenize
> and emit a warning, or reject the translation unit.  GCC v3 opts for
> choice 2, and judging by the sheer number of complaints I've received,
> most of the "existing conforming (albeit not strictly conforming)
> programs" out there that depend on this undefined behavior expect choice 1.

This is exactly what I mean.  Such a specification would simply formalize what
already happens in nearly every implementation, and by definition wouldn't break
any code.

Paul Mensonides

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In comp.std.c, Douglas A. Gwyn <DAGwyn@null.net> writes:
>Zack Weinberg wrote:
>> I believe he said that all the implementations he has tested do exactly
>> this?
>
>No, as you said, many issue a warning, which would have to be changed.

No - the standard makes no requirements on when warnings do or do
not occur.  Even just on QoI grounds, changing the text from "pasting
%s and %s gives undefined behavior" to "pasting %s and %s gives
undefined behavior prior to C2009" would suffice to make the warning
useful again.  And no matter what change is made, it touches no
more than two lines of the implementation's code; hardly a burden.

>Also I suspect there is at least one implementation somewhere that
>does reject the translation unit, and it might not be easy to change
>it to re-tokenize at a stage where it never had to before.

Granted - if such an implementation exists - can you name one?

zw

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Zack Weinberg" <zackw@panix.com> wrote in message
news:ajeu8l$8ld$1@panix1.panix.com...
> In comp.std.c, Douglas A. Gwyn <DAGwyn@null.net> writes:
> >Zack Weinberg wrote:
> >> I believe he said that all the implementations he has tested do exactly
> >> this?
> >
> >No, as you said, many issue a warning, which would have to be changed.
>
> No - the standard makes no requirements on when warnings do or do
> not occur.  Even just on QoI grounds, changing the text from "pasting
> %s and %s gives undefined behavior" to "pasting %s and %s gives
> undefined behavior prior to C2009" would suffice to make the warning
> useful again.  And no matter what change is made, it touches no
> more than two lines of the implementation's code; hardly a burden.

This would be an easy change to make, and it only 'officializes' what most
implementations already do.  The problem, specifically, is that C99 allows
nothing to be passed as a macro parameter.  This makes it impossible (as far as
I can tell) to determine the difference between one or zero arguments.  The
presence of commas allow the detection of everything else:

X() // zero or one parameter?

-vs.-

X(,) // two parameters

I am currently developing the Boost Preprocessor library (which is a
metaprogramming library), and I'd like to support C99 features whenever
possible.  This means introducing the only C99 code in all of Boost.  By doing
so, I am setting a precedent for inclusion of variadic macros in C++0x.

Making the result well-defined (i.e. re-tokenization) would just standardize
what most people expect already (because that is exactly what most
implementations do).

> >Also I suspect there is at least one implementation somewhere that
> >does reject the translation unit, and it might not be easy to change
> >it to re-tokenize at a stage where it never had to before.
>
> Granted - if such an implementation exists - can you name one?

Also, how many implementations support variadic macros right now?  I doubt that
there is that many, and that is much more significant modification to the
preprocessor than well-defining token-pasting.

Paul Mensonides

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Paul Mensonides wrote:
> Making the result well-defined (i.e. re-tokenization) would just standardize
> what most people expect already (because that is exactly what most
> implementations do).

Well, *I* certainly don't expect retokenization except upon paste.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Douglas A. Gwyn" <DAGwyn@null.net> wrote in message
news:3D5D5304.9677D24C@null.net...
> Paul Mensonides wrote:
> > Making the result well-defined (i.e. re-tokenization) would just standardize
> > what most people expect already (because that is exactly what most
> > implementations do).
>
> Well, *I* certainly don't expect retokenization except upon paste.

What do you mean?  You don't expect is *except* upon paste?  I'm not sure what
you mean.  Token-pasting is what I'm talking about.  For instance,

#define MACRO(a, b) a ## b

MACRO(!, x)

This currently is undefined.  However, the result should be well-defined to be
the two tokens: '!' and 'x'.  Are you saying that would be bad?

Paul Mensonides


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Paul Mensonides wrote:
> "Douglas A. Gwyn" <DAGwyn@null.net> wrote ///
> > Well, *I* certainly don't expect retokenization except upon paste.
> What do you mean?

I mean, except that pasting produces a new token.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]