Re: Challenging macro with default value

Discussion in 'C Programming' started by Dan Pop, Apr 1, 2004.

  1. Dan Pop

    Dan Pop Guest

    In <> Kevin Bracey <> writes:

    >In message <c4er37$3cn$>
    > (Dan Pop) wrote:
    >
    >> In <> Kevin Bracey <> writes:
    >>
    >> >In message <>
    >> > Jeremy Yallop <> wrote:
    >> >
    >> > > GCC (wrongly) accepts code that invokes a one-argument macro with no
    >> > > arguments. The C standards say that such code requires a diagnostic.
    >> > > Other compilers correctly reject the code.
    >> >
    >> > Lots of people on this thread have said that this is wrong, but no-one
    >> > seems to have noticed that it is valid in C99. If you have
    >> >
    >> > #define MYMACRO(n) /* Whatever */
    >> >
    >> >then it is legal to invoke MYMACRO() - that passes one empty argument,

    >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    >> Can we have a chapter and verse for this? If it were true, we'd have
    >> big troubles invoking the following macro:
    >>
    >> #define FOO() bla
    >>
    >> because there is no way to invoke it without any arguments

    >
    >That's resolved by the interpretation of the invocation being dependent on
    >the form of the definition. So an invocation FOO() is treated as having no
    >arguments. I'm getting this from rationale 6.10.3, last part. As to whether
    >the standard says what the rationale thinks it does, I confess I can't see it
    >explicitly stated.


    So, you are unable to support your position with a normative quote from
    the standard. Yet, you claim that ERT is right...

    >> > Did C90 really require a diagnostic? My C90 compilers don't give one, and
    >> > the C rationale says that it was undefined behaviour. A previous thread
    >> > in comp.std.c titled "Empty macro arguments" appears to concur.

    >>
    >> According to my C89 draft, it's a constraint violation:
    >>
    >> 3.8.3 Macro replacement
    >>
    >> Constraints
    >> ...
    >> The number of arguments in an invocation of a function-like macro
    >> shall agree with the number of parameters in the macro definition, and
    >> there shall exist a ) preprocessing token that terminates the
    >> invocation.
    >>
    >> Note that empty macro arguments being a new C99 feature, there is no way
    >> to interpret MYMACRO() as having one empty argument.

    >
    >That depends. Empty macro arguments actually doing something in a defined way
    >is a new C99 feature, but if the concept of an empty argument existed in C89,
    >then it could be viewed that way.


    The C89 standard (my draft, at least), lists them as common extensions.

    >I don't have C89/C90 to hand, but if it said that an empty argument invoked
    >undefined behaviour, I think that MYMACRO() could quite happily fall into
    >that category.


    Empty arguments do NOT exist in C89, therefore you have a clear case of
    constraint violation.

    >That appears to be the point of view of the rationale, which says it was
    >undefined behaviour (but noted as a common extension).


    There is no way to justify undefined behaviour, based on the actual text
    of C89, unless you can prove otherwise.

    The common extensions appendix is misleading, because it lists extensions
    that break the implementation conformance without mentioning it. E.g. the
    "asm" keyword that is also mentioned as a common extension.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 1, 2004
    #1
    1. Advertising

  2. Dan Pop wrote:
    > In <> Kevin Bracey <> writes:
    >>I don't have C89/C90 to hand, but if it said that an empty argument invoked
    >>undefined behaviour, I think that MYMACRO() could quite happily fall into
    >>that category.

    >
    > Empty arguments do NOT exist in C89, therefore you have a clear case of
    > constraint violation.
    >
    >>That appears to be the point of view of the rationale, which says it was
    >>undefined behaviour (but noted as a common extension).

    >
    > There is no way to justify undefined behaviour, based on the actual text
    > of C89, unless you can prove otherwise.


    C89 (3.8.3) has the following text:

    If (before argument substitution) any argument consists of no
    preprocessing tokens, the behavior is undefined.

    Jeremy.
     
    Jeremy Yallop, Apr 1, 2004
    #2
    1. Advertising

  3. Dan Pop

    Kevin Bracey Guest

    In message <c4has2$b4d$>
    (Dan Pop) wrote:

    > So, you are unable to support your position with a normative quote from
    > the standard. Yet, you claim that ERT is right...


    My position is the same as the Committee's. I suggest you take it up with
    them about whether their position can be supported with a normative quote
    from the standard. They seem to think so (see DR#259). I'm not so convinced,
    but I'm not terribly interested in being a language lawyer; I know what my
    implementation is supposed to do, so that's enough for me.

    > > I don't have C89/C90 to hand, but if it said that an empty argument
    > > invoked undefined behaviour, I think that MYMACRO() could quite happily
    > > fall into that category.

    >
    > Empty arguments do NOT exist in C89, therefore you have a clear case of
    > constraint violation.


    So what about this in C89? How many arguments?

    #define FRED (x,y)

    FRED(3,)

    Is it 1, thus a clear constraint violation? I don't think that would be
    the general view, but I may be wrong.

    If it is 2 arguments, the 2nd one is definitely an empty argument. Thus the
    concept of empty arguments exists. I assume this case is undefined behavior.

    --
    Kevin Bracey, Principal Software Engineer
    Tematic Ltd Tel: +44 (0) 1223 503464
    182-190 Newmarket Road Fax: +44 (0) 1223 503458
    Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
     
    Kevin Bracey, Apr 1, 2004
    #3
  4. Dan Pop

    Dan Pop Guest

    In <> Jeremy Yallop <> writes:

    >Dan Pop wrote:
    >> In <> Kevin Bracey <> writes:
    >>>I don't have C89/C90 to hand, but if it said that an empty argument invoked
    >>>undefined behaviour, I think that MYMACRO() could quite happily fall into
    >>>that category.

    >>
    >> Empty arguments do NOT exist in C89, therefore you have a clear case of
    >> constraint violation.
    >>
    >>>That appears to be the point of view of the rationale, which says it was
    >>>undefined behaviour (but noted as a common extension).

    >>
    >> There is no way to justify undefined behaviour, based on the actual text
    >> of C89, unless you can prove otherwise.

    >
    >C89 (3.8.3) has the following text:
    >
    > If (before argument substitution) any argument consists of no
    > preprocessing tokens, the behavior is undefined.


    This is not good enough: is there any argument at all in an empty argument
    list? If there is, then we have a problem when expanding the invocations
    of parameterless macros: the macro invocation contains of ONE argument!

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 1, 2004
    #4
  5. Dan Pop

    Dan Pop Guest

    In <> Kevin Bracey <> writes:

    >In message <c4has2$b4d$>
    > (Dan Pop) wrote:
    >
    >> So, you are unable to support your position with a normative quote from
    >> the standard. Yet, you claim that ERT is right...

    >
    >My position is the same as the Committee's. I suggest you take it up with
    >them about whether their position can be supported with a normative quote
    >from the standard. They seem to think so (see DR#259). I'm not so convinced,
    >but I'm not terribly interested in being a language lawyer; I know what my
    >implementation is supposed to do, so that's enough for me.


    Do you have *any* customers/users or are you the only user of your
    implementation? If one of your customers complains, how can you *prove*
    that your implementation is conforming to the normative text of the
    standard? By quoting a DR that concludes that the text that fails to
    convince you (and not only you) is crystal clear?

    >> > I don't have C89/C90 to hand, but if it said that an empty argument
    >> > invoked undefined behaviour, I think that MYMACRO() could quite happily
    >> > fall into that category.

    >>
    >> Empty arguments do NOT exist in C89, therefore you have a clear case of
    >> constraint violation.

    >
    >So what about this in C89? How many arguments?
    >
    > #define FRED (x,y)
    >
    > FRED(3,)
    >
    >Is it 1, thus a clear constraint violation? I don't think that would be
    >the general view, but I may be wrong.
    >
    >If it is 2 arguments, the 2nd one is definitely an empty argument. Thus the
    >concept of empty arguments exists. I assume this case is undefined behavior.


    Agreed. You have two arguments and one of them is empty: explicit
    undefined behaviour:

    If (before argument substitution) any argument consists of no
    preprocessing tokens, the behavior is undefined.

    However, this does NOT cover the case of macros defined with one
    parameter and invoked with an empty parameter list. I have already
    explained the contradiction that would arise otherwise: parameterless
    macros could not be called without invoking undefined behaviour, because
    the argument list would contain an argument consisting of no preprocessing
    tokens, which is undefined behaviour.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 1, 2004
    #5
  6. Dan Pop

    Kevin Bracey Guest

    In message <c4hmam$9kk$>
    (Dan Pop) wrote:

    > In <> Kevin Bracey <> writes:
    >
    > > My position is the same as the Committee's. I suggest you take it up with
    > > them about whether their position can be supported with a normative quote
    > > from the standard. They seem to think so (see DR#259). I'm not so
    > > convinced, but I'm not terribly interested in being a language lawyer; I
    > > know what my implementation is supposed to do, so that's enough for me.

    >
    > Do you have *any* customers/users or are you the only user of your
    > implementation? If one of your customers complains, how can you *prove*
    > that your implementation is conforming to the normative text of the
    > standard? By quoting a DR that concludes that the text that fails to
    > convince you (and not only you) is crystal clear?


    You're being rather Dan Pop-ish about this. The intent of the standard is
    crystal-clear, as it is spelled out in several non-normative places:

    1) The summary of new C99 features mentions empty arguments.
    2) At least 1 example in the main standard shows it being used.
    3) The C99 rationale has *two whole paragraphs* explaining the feature.
    4) The response DR#259 confirms the committee's view that the normative
    text reflects the intended use.

    Only a complete lunatic (or someone who just likes arguing for the sake of
    it) would argue that our compiler was actually wrong. Although they might
    be on firmer ground in C90 mode, where it still accepts it, as I'm willing to
    view this as undefined behaviour (as per the rationale).

    I don't quite see why you're so upset about this. If you want to resubmit
    something along the lines of DR#259, I'd support you, but I really don't
    believe for one second that you think our compiler is wrong to be following
    the committee's explicitly expressed intent.

    > >So what about this in C89? How many arguments?
    > >
    > > #define FRED (x,y)
    > >
    > > FRED(3,)
    > >
    > >Is it 1, thus a clear constraint violation? I don't think that would be
    > >the general view, but I may be wrong.
    > >
    > > If it is 2 arguments, the 2nd one is definitely an empty argument. Thus
    > > the concept of empty arguments exists. I assume this case is undefined
    > > behavior.

    >
    > Agreed. You have two arguments and one of them is empty: explicit
    > undefined behaviour:
    >
    > If (before argument substitution) any argument consists of no
    > preprocessing tokens, the behavior is undefined.
    >
    > However, this does NOT cover the case of macros defined with one
    > parameter and invoked with an empty parameter list. I have already
    > explained the contradiction that would arise otherwise: parameterless
    > macros could not be called without invoking undefined behaviour, because
    > the argument list would contain an argument consisting of no preprocessing
    > tokens, which is undefined behaviour.


    To resolve the contradiction, you need to take the step which the committee
    seem to think is implicit in C99: the empty parentheses are a multipurpose
    beast which can either be viewed as containing 1 empty argument or no
    arguments, and you choose the view which matches the definition.

    So if your definition has 1 parameter, you choose the view of it being 1
    empty argument, and get undefined behaviour, rather than a constraint
    violation.

    As far as I can see, the polymorphic nature of the empty parentheses required
    to avoid the constraint (giving undefined behaviour instead) in C90 is
    exactly that required to get defined behaviour in C99, and it seems to me to
    be equally unstated in both standards.

    --
    Kevin Bracey, Principal Software Engineer
    Tematic Ltd Tel: +44 (0) 1223 503464
    182-190 Newmarket Road Fax: +44 (0) 1223 503458
    Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
     
    Kevin Bracey, Apr 1, 2004
    #6
  7. Dan Pop

    Dan Pop Guest

    In <> Kevin Bracey <> writes:

    >In message <c4hmam$9kk$>
    > (Dan Pop) wrote:
    >
    >> In <> Kevin Bracey <> writes:
    >>
    >> > My position is the same as the Committee's. I suggest you take it up with
    >> > them about whether their position can be supported with a normative quote
    >> > from the standard. They seem to think so (see DR#259). I'm not so
    >> > convinced, but I'm not terribly interested in being a language lawyer; I
    >> > know what my implementation is supposed to do, so that's enough for me.

    >>
    >> Do you have *any* customers/users or are you the only user of your
    >> implementation? If one of your customers complains, how can you *prove*
    >> that your implementation is conforming to the normative text of the
    >> standard? By quoting a DR that concludes that the text that fails to
    >> convince you (and not only you) is crystal clear?

    >
    >You're being rather Dan Pop-ish about this. The intent of the standard is
    >crystal-clear, as it is spelled out in several non-normative places:


    If you have to read several non-normative texts in order to be able to
    figure it out, then the intent *of the standard* is far from
    crystal-clear. This is my point and you have produced until now zilch
    evidence to the contrary.

    >Only a complete lunatic (or someone who just likes arguing for the sake of
    >it) would argue that our compiler was actually wrong.


    Could you justify its behaviour based *exclusively* on the *normative*
    text of the standard? If someone quotes

    4 If the identifier-list in the macro definition does not end with
    an ellipsis, the number of arguments (including those arguments
    consisting of no preprocessing tokens) in an invocation of a
    function-like macro shall equal the number of parameters in the
    macro definition. ^^^^^^^^^^^

    to you and complains about the lack of diagnostic, what *normative* part
    of the text of the standard can you use in your defence?

    I do not deny the fact that your compiler implements the intent of the
    people who wrote the standard, but this intent is at odds with the
    normative text of the standard.

    >Although they might
    >be on firmer ground in C90 mode, where it still accepts it, as I'm willing to
    >view this as undefined behaviour (as per the rationale).


    Again, you're ignoring the normative text of the C90 standard in favour of
    its rationale, which is a silly thing to do. The C90 standard contains
    the same constraint quoted above and, just like C99, no suggestion that
    MACRO() is a macro invocation with one argument.

    >I don't quite see why you're so upset about this.


    I am upset every time people say that the broken text of the standard
    constitutes no problem, because the Rationale or some other non-normative
    text clearly explains the committee intent. It is the normative text of
    the standard itself that MUST clearly explain the committee intent.

    In this particular case, when DR 259 (submitted by a committee member)
    proposed a small addition to the normative text, to make it clearly
    reflect the committee intent, the committee answer was that the current
    text of the standard is clear enough. Isn't this sheer idiocy?

    >If you want to resubmit something along the lines of DR#259,


    If Clive Feather's DR was arrogantly rejected, only a fool could hope to
    have more success.

    >I'd support you, but I really don't
    >believe for one second that you think our compiler is wrong to be following
    >the committee's explicitly expressed intent.


    Explicitly expressed where in the normative text of the standard?
    This text explicitly says the opposite, as quoted above.

    If I were an implementor, I'd add a compiler option to deal with this
    feature, so that the user could select between the standard and its
    rationale. I see no point in enforcing the committee intent, as long as
    the actual standard explicitly says something else.

    >> However, this does NOT cover the case of macros defined with one
    >> parameter and invoked with an empty parameter list. I have already
    >> explained the contradiction that would arise otherwise: parameterless
    >> macros could not be called without invoking undefined behaviour, because
    >> the argument list would contain an argument consisting of no preprocessing
    >> tokens, which is undefined behaviour.

    >
    >To resolve the contradiction, you need to take the step which the committee
    >seem to think is implicit in C99: the empty parentheses are a multipurpose
    >beast which can either be viewed as containing 1 empty argument or no
    >arguments, and you choose the view which matches the definition.
    >
    >So if your definition has 1 parameter, you choose the view of it being 1
    >empty argument, and get undefined behaviour, rather than a constraint
    >violation.
    >
    >As far as I can see, the polymorphic nature of the empty parentheses required
    >to avoid the constraint (giving undefined behaviour instead) in C90 is
    >exactly that required to get defined behaviour in C99, and it seems to me
    >to be equally unstated in both standards.

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Therefore, empty parentheses have NO polymorphic nature in either
    standard, period. If the committee wanted such a nature, the right place
    to describe it was the normative text of the standard, not its Rationale.

    Having it described in the Rationale may be good enough for you, but it's
    not good enough for anyone who believes that the Rationale cannot override
    the normative text of the standard. And this text still contains the text
    I have quoted above...

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 2, 2004
    #7
  8. Dan Pop

    Kevin Bracey Guest

    In message <c4jjop$3ui$>
    (Dan Pop) wrote:

    > If you have to read several non-normative texts in order to be able to
    > figure it out, then the intent *of the standard* is far from
    > crystal-clear. This is my point and you have produced until now zilch
    > evidence to the contrary.


    How many angels can Dan Pop fit on the head of a pin? I assume you're arguing
    that the intent of the standard can be different from the intent of its
    authors. Only something conscious can have an intent of its own; the
    standard's intent must be that of its authors.

    It's possible that the *meaning* of the standard could be different from the
    intent of its authors though. But not being a religious sort, I'd take the
    authors' word as a higher authority than the written text, in anticipation of
    the written text being fixed.

    > >Only a complete lunatic (or someone who just likes arguing for the sake of
    > >it) would argue that our compiler was actually wrong.

    >
    > Could you justify its behaviour based *exclusively* on the *normative*
    > text of the standard?


    No, I don't think so.

    > If someone quotes
    >
    > 4 If the identifier-list in the macro definition does not end with
    > an ellipsis, the number of arguments (including those arguments
    > consisting of no preprocessing tokens) in an invocation of a
    > function-like macro shall equal the number of parameters in the
    > macro definition. ^^^^^^^^^^^
    >
    > to you and complains about the lack of diagnostic, what *normative* part
    > of the text of the standard can you use in your defence?


    I'd refer them to the rationale, and point out that MACRO1() has one empty
    argument. Then I'd ask them to contradict that statement on the basis of the
    normative text.

    If I were to refuse the construct and give a diagnostic, I don't think I
    could justify that on the basis of just the normative text. And then I
    wouldn't have the rationale to fall back on :)

    > Again, you're ignoring the normative text of the C90 standard in favour of
    > its rationale, which is a silly thing to do. The C90 standard contains
    > the same constraint quoted above and, just like C99, no suggestion that
    > MACRO() is a macro invocation with one argument.


    I don't agree that I'm ignoring anything; I believe that MACRO1() has 1 empty
    argument if it's defined as having 1 parameter, so the constraint does not
    apply. This behaviour arises naturally from the implementation of the
    preprocessor - why should it treat the 2nd argument of MACRO2(x,) any
    differently from the first argument of MACRO1() - either way it ends up
    reading an empty argument.

    The standard doesn't say that MACRO1() has one empty argument, but it doesn't
    say that has no arguments either. Does it?

    > I am upset every time people say that the broken text of the standard
    > constitutes no problem, because the Rationale or some other non-normative
    > text clearly explains the committee intent.


    I'm not saying it isn't _a_ problem. But it's not a problem for me as an
    implementor (or user).

    > >If you want to resubmit something along the lines of DR#259,

    >
    > If Clive Feather's DR was arrogantly rejected, only a fool could hope to
    > have more success.


    Maybe we could start a petition :) Or lobby our MPs :)

    > > I'd support you, but I really don't believe for one second that you think
    > > our compiler is wrong to be following the committee's explicitly
    > > expressed intent.

    >
    > Explicitly expressed where in the normative text of the standard?


    Enough already...

    --
    Kevin Bracey, Principal Software Engineer
    Tematic Ltd Tel: +44 (0) 1223 503464
    182-190 Newmarket Road Fax: +44 (0) 1223 503458
    Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
     
    Kevin Bracey, Apr 2, 2004
    #8
  9. Dan Pop

    Dan Pop Guest

    In <> Kevin Bracey <> writes:

    >In message <c4jjop$3ui$>
    > (Dan Pop) wrote:
    >
    >> If you have to read several non-normative texts in order to be able to
    >> figure it out, then the intent *of the standard* is far from
    >> crystal-clear. This is my point and you have produced until now zilch
    >> evidence to the contrary.

    >
    >It's possible that the *meaning* of the standard could be different from the
    >intent of its authors though. But not being a religious sort, I'd take the
    >authors' word as a higher authority than the written text, in anticipation of
    >the written text being fixed.


    That would make perfect sense if the answer to DR 259 fixed the text of
    the standard, even without waiting for the answer to become part of a
    normative TC. However, when the committee refused to do that, it is
    plain foolishess to anticipate the written text being fixed.

    >> Could you justify its behaviour based *exclusively* on the *normative*
    >> text of the standard?

    >
    >No, I don't think so.


    That's the point!

    >> If someone quotes
    >>
    >> 4 If the identifier-list in the macro definition does not end with
    >> an ellipsis, the number of arguments (including those arguments
    >> consisting of no preprocessing tokens) in an invocation of a
    >> function-like macro shall equal the number of parameters in the
    >> macro definition. ^^^^^^^^^^^
    >>
    >> to you and complains about the lack of diagnostic, what *normative* part
    >> of the text of the standard can you use in your defence?

    >
    >I'd refer them to the rationale, and point out that MACRO1() has one empty
    >argument. Then I'd ask them to contradict that statement on the basis of the
    >normative text.


    That's precisely what I've done in my posts, by pointing out the immediate
    contradiction that arises if MACRO1() has one empty argument: MACRO0()
    *must* have exactly the same number of arguments and the standard doesn't
    say anywhere that it doesn't. And the direct consequence of this is that
    MACRO0 *cannot* be correctly invoked.

    >If I were to refuse the construct and give a diagnostic, I don't think I
    >could justify that on the basis of just the normative text.


    I have provided you enough ammunition, haven't I? ;-)

    >The standard doesn't say that MACRO1() has one empty argument, but it doesn't
    >say that has no arguments either. Does it?


    Does the standard say or imply anywhere that MACRO1() and MACRO0() have a
    different number of arguments and how to count them in each case?

    >> I am upset every time people say that the broken text of the standard
    >> constitutes no problem, because the Rationale or some other non-normative
    >> text clearly explains the committee intent.

    >
    >I'm not saying it isn't _a_ problem. But it's not a problem for me as an
    >implementor (or user).


    It may well be a problem for you as a user if you actually use this
    feature in your code and have to port it to another compiler, whose
    implementor didn't bother to read (or believe) any non-normative text...

    BTW, if your C90 implementation treated MACRO1() as an error, would
    you have been so eager to buy the Rationale stuff and change your
    compiler's behaviour?

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 2, 2004
    #9
  10. Dan Pop

    Alan Balmer Guest

    On Fri, 02 Apr 2004 14:27:37 +0100, Kevin Bracey
    <> wrote:

    >In message <c4jjop$3ui$>
    > (Dan Pop) wrote:
    >
    >> If you have to read several non-normative texts in order to be able to
    >> figure it out, then the intent *of the standard* is far from
    >> crystal-clear. This is my point and you have produced until now zilch
    >> evidence to the contrary.

    >
    >How many angels can Dan Pop fit on the head of a pin? I assume you're arguing
    >that the intent of the standard can be different from the intent of its
    >authors. Only something conscious can have an intent of its own; the
    >standard's intent must be that of its authors.


    The standard itself has no "intent." It may reflect the intent of its
    authors, but it's the responsibility of the authors to make it do so
    well enough to be a working tool. In this case, it seems they have
    failed.

    The rationale and other non-normative texts may help to justify and
    illustrate the standard, but they are not the standard. They are
    certainly more valuable than (say) Schildt's commentary, but fall into
    the same category.

    --
    Al Balmer
    Balmer Consulting
     
    Alan Balmer, Apr 2, 2004
    #10
  11. Dan Pop

    Kevin Bracey Guest

    In message <c4ju0r$57g$>
    (Dan Pop) wrote:

    > In <> Kevin Bracey <> writes:
    >
    > > I'd refer them to the rationale, and point out that MACRO1() has one
    > > empty argument. Then I'd ask them to contradict that statement on the
    > > basis of the normative text.

    >
    > That's precisely what I've done in my posts, by pointing out the immediate
    > contradiction that arises if MACRO1() has one empty argument: MACRO0()
    > *must* have exactly the same number of arguments and the standard doesn't
    > say anywhere that it doesn't.


    I don't agree with that. Why must MACRO0() have the same number of arguments
    as MACRO1()? Why can't the interpretation of a piece of source text be
    affected by prior definitions? Eg, "myIdentifier1" and "myIdentifier2" can be
    a type and a variable name, respectively.

    There is no formal syntax given for the arguments of a macro invocation,
    maybe partly because of this syntactical ambiguity. The empty list of
    tokens can equally well be viewed as no arguments or one empty argument,
    and I see nothing that forces me to always view it the same way.

    Indeed, the phrasing in p11 "the sequence of preprocessing tokens ... forms
    the list of arguments" does suggest to me that you are reading that sequence
    with the aim of providing your arguments, so your expectations may quite
    reasonably affect your interpretation.

    > > The standard doesn't say that MACRO1() has one empty argument, but it
    > > doesn't say that has no arguments either. Does it?

    >
    > Does the standard say or imply anywhere that MACRO1() and MACRO0() have a
    > different number of arguments and how to count them in each case?


    Not as far as I can see. I suspect the problem is that it seemed "obvious"
    to the authors that they would be treated differently, as that's what
    a simplistic preprocessor implementation would do automatically, depending
    on the number of parameters of the macro:

    Read "(";
    For (i = 1; i <= num_params; i++)
    {
    Read Tokens Into Arg Up To ',' or ')' [Matching parentheses]
    if (NextToken == ')')
    { if (i != num_args)
    Diagnostic("Too few arguments");
    break;
    }
    SkipToken; // skip over comma
    }
    if (NextToken == ')')
    SkipToken;
    else
    Diagnostic("Expected ')', inserted before %NextToken");

    I don't see anything in the standard that says that MACRO1() and MACRO0()
    have to have the same number of arguments, so I don't see a water-tight
    case for claiming that MACRO1() requires a diagnostic.

    Thus I don't believe that the Rationale actually contradicts the normative
    text. But it does specify behaviour that isn't stated in the normative text.

    > BTW, if your C90 implementation treated MACRO1() as an error, would
    > you have been so eager to buy the Rationale stuff and change your
    > compiler's behaviour?


    It's not a biggie, compared to most of the stuff in C99. I would have
    definitely changed it. I don't know whether I'd have changed the C90 mode to
    match. Probably not; the compiler is fairly strict and does tend to give
    diagnostics for cases of undefined behaviour where it can spot them, as a
    rule, although it never warned about empty arguments. I don't like to make
    it more lax.

    Empty macro arguments is nothing compared to adding 64-bit integers and
    complex numbers, which I had to do for C99. And compound literals were
    horrible, due to the nasty nesting tricks you can do. Not to mention all the
    new <math.h> functions. And Annex F, when I get around to it :(

    --
    Kevin Bracey, Principal Software Engineer
    Tematic Ltd Tel: +44 (0) 1223 503464
    182-190 Newmarket Road Fax: +44 (0) 1223 503458
    Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
     
    Kevin Bracey, Apr 2, 2004
    #11
  12. Dan Pop

    Dan Pop Guest

    In <> Kevin Bracey <> writes:

    >In message <c4ju0r$57g$>
    > (Dan Pop) wrote:
    >
    >> In <> Kevin Bracey <> writes:
    >>
    >> > I'd refer them to the rationale, and point out that MACRO1() has one
    >> > empty argument. Then I'd ask them to contradict that statement on the
    >> > basis of the normative text.

    >>
    >> That's precisely what I've done in my posts, by pointing out the immediate
    >> contradiction that arises if MACRO1() has one empty argument: MACRO0()
    >> *must* have exactly the same number of arguments and the standard doesn't
    >> say anywhere that it doesn't.

    >
    >I don't agree with that. Why must MACRO0() have the same number of arguments
    >as MACRO1()? Why can't the interpretation of a piece of source text be
    >affected by prior definitions?


    It *could* if the standard said so. But, when I challenged you to point
    out the chapter and verse, you merely agreed that the standard doesn't
    say so.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Apr 2, 2004
    #12
  13. Kevin Bracey <> writes:
    > In message <c4ju0r$57g$>
    > (Dan Pop) wrote:
    >
    > > In <> Kevin Bracey
    > > <> writes:
    > >
    > > > I'd refer them to the rationale, and point out that MACRO1() has one
    > > > empty argument. Then I'd ask them to contradict that statement on the
    > > > basis of the normative text.

    > >
    > > That's precisely what I've done in my posts, by pointing out the immediate
    > > contradiction that arises if MACRO1() has one empty argument: MACRO0()
    > > *must* have exactly the same number of arguments and the standard doesn't
    > > say anywhere that it doesn't.

    >
    > I don't agree with that. Why must MACRO0() have the same number of arguments
    > as MACRO1()? Why can't the interpretation of a piece of source text be
    > affected by prior definitions? Eg, "myIdentifier1" and "myIdentifier2" can be
    > a type and a variable name, respectively.


    Because the normative text of the standard doesn't say so. Because
    invocations of function-like macros are syntactically similar to
    function calls, and the number of arguments in a function call can
    always be determined without reference to the function definition.
    (That's admittedly a somewhat weaker argument, since function calls
    can't have empty arguments.) Because there's no basis in the
    normative text of the standard for assuming that MACRO0() and MACRO1()
    should be parsed differently unless you assume in advance that they
    should be parsed differently.

    Suppose I wanted to define a hypothetical language very similar to
    C99, *except* that the number of arguments in a macro invocation can
    always be determined without reference to the macro definition. Empty
    arguments are still allowed, but there's no mechanism for passing a
    single empty argument. Rationale: an invocation MACRO1() is more
    likely to be an error than a deliberate attempt to pass an empty
    argument, and it's more important to diagnose the error than to allow
    a single empty argument. If you need to pass an empty argument,
    change the macro definition so it takes two parameters, and invoke it
    as MACRO2(,); the bare comma unambiguously indicates that there are
    two empty arguments, one of which can be ignored.

    Now I'm not saying that this is a better approach than the one taken
    by C99 (I kinda like it myself, but I'm willing to accept the intent
    of the committee). But the question is, how is the current normative
    text of the C99 standard inconsistent with this hypothetical language?

    Step back for a moment and pretend that MACRO0() and MACRO1() should
    be parsed identically, each specifying a macro invocation with no
    arguments. (That's the assumption I made when I first read it, and I
    believe it was a reasonable one.) Then re-read that portion of the
    standard (without reference to the footnotes) and point out where the
    wording is inconsistent with that assumption. If there is no such
    inconsistency, then the current wording is at least ambiguous, and
    should be corrected.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
     
    Keith Thompson, Apr 2, 2004
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?cmFtYXRh?=

    Classical Complex challenging Asp and SQL problem

    =?Utf-8?B?cmFtYXRh?=, Apr 30, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    469
    Mark Rae
    May 3, 2005
  2. John Timney \(ASP.NET MVP\)

    Re: Why Web Programming is so Challenging and Different

    John Timney \(ASP.NET MVP\), Sep 20, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    426
    John Timney \(ASP.NET MVP\)
    Sep 20, 2005
  3. Keith Thompson

    Re: Challenging macro with default value

    Keith Thompson, Apr 1, 2004, in forum: C Programming
    Replies:
    7
    Views:
    350
    cturtle
    Apr 6, 2004
  4. sounak

    to get macro name from macro value

    sounak, Nov 22, 2005, in forum: C Programming
    Replies:
    17
    Views:
    514
    Mark McIntyre
    Nov 22, 2005
  5. aleksa

    Macro with a default value

    aleksa, Nov 14, 2010, in forum: C Programming
    Replies:
    5
    Views:
    352
    Keith Thompson
    Nov 14, 2010
Loading...

Share This Page