Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Challenging macro with default value

Reply
Thread Tools

Re: Challenging macro with default value

 
 
Dan Pop
Guest
Posts: n/a
 
      04-01-2004
In <(E-Mail Removed)> Kevin Bracey <(E-Mail Removed)> writes:

>In message <c4er37$3cn$(E-Mail Removed)>
> http://www.velocityreviews.com/forums/(E-Mail Removed) (Dan Pop) wrote:
>
>> In <(E-Mail Removed)> Kevin Bracey <(E-Mail Removed)> writes:
>>
>> >In message <(E-Mail Removed)>
>> > Jeremy Yallop <(E-Mail Removed)> 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: (E-Mail Removed)
 
Reply With Quote
 
 
 
 
Jeremy Yallop
Guest
Posts: n/a
 
      04-01-2004
Dan Pop wrote:
> In <(E-Mail Removed)> Kevin Bracey <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Kevin Bracey
Guest
Posts: n/a
 
      04-01-2004
In message <c4has2$b4d$(E-Mail Removed)>
(E-Mail Removed) (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/
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      04-01-2004
In <(E-Mail Removed)> Jeremy Yallop <(E-Mail Removed)> writes:

>Dan Pop wrote:
>> In <(E-Mail Removed)> Kevin Bracey <(E-Mail Removed)> 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: (E-Mail Removed)
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      04-01-2004
In <(E-Mail Removed)> Kevin Bracey <(E-Mail Removed)> writes:

>In message <c4has2$b4d$(E-Mail Removed)>
> (E-Mail Removed) (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: (E-Mail Removed)
 
Reply With Quote
 
Kevin Bracey
Guest
Posts: n/a
 
      04-01-2004
In message <c4hmam$9kk$(E-Mail Removed)>
(E-Mail Removed) (Dan Pop) wrote:

> In <(E-Mail Removed)> Kevin Bracey <(E-Mail Removed)> 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/
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      04-02-2004
In <(E-Mail Removed)> Kevin Bracey <(E-Mail Removed)> writes:

>In message <c4hmam$9kk$(E-Mail Removed)>
> (E-Mail Removed) (Dan Pop) wrote:
>
>> In <(E-Mail Removed)> Kevin Bracey <(E-Mail Removed)> 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: (E-Mail Removed)
 
Reply With Quote
 
Kevin Bracey
Guest
Posts: n/a
 
      04-02-2004
In message <c4jjop$3ui$(E-Mail Removed)>
(E-Mail Removed) (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/
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      04-02-2004
In <(E-Mail Removed)> Kevin Bracey <(E-Mail Removed)> writes:

>In message <c4jjop$3ui$(E-Mail Removed)>
> (E-Mail Removed) (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: (E-Mail Removed)
 
Reply With Quote
 
Alan Balmer
Guest
Posts: n/a
 
      04-02-2004
On Fri, 02 Apr 2004 14:27:37 +0100, Kevin Bracey
<(E-Mail Removed)> wrote:

>In message <c4jjop$3ui$(E-Mail Removed)>
> (E-Mail Removed) (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
(E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Macro with a default value aleksa C Programming 5 11-14-2010 09:13 PM
Challenging problem: Intermittent issues with secure site(s) Matthew Wireless Networking 3 05-09-2006 05:41 PM
to get macro name from macro value sounak C Programming 17 11-22-2005 11:12 PM
Classical Complex challenging Asp and SQL problem =?Utf-8?B?cmFtYXRh?= ASP .Net 3 05-03-2005 07:18 AM
Re: Challenging macro with default value Keith Thompson C Programming 7 04-06-2004 08:53 PM



Advertisments