Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Macro problems between GNU C and Microsoft C

Reply
Thread Tools

Re: Macro problems between GNU C and Microsoft C

 
 
spinoza1111
Guest
Posts: n/a
 
      06-03-2010
On Jun 3, 10:52*pm, Frank GOENNINGER <(E-Mail Removed)> wrote:
> Hi all:
>
> Having been coding for more than 20 years in various Unix/Linux/OS X
> flavors I am now challenged to work on Windows.
>
> I have:
>
> <code>
>
> #define AMQP_CHECK_RESULT_CLEANUP(expr, stmts) *\
> * ({ * * * * * * * * * * * * * * * * * * * * * *\
> * * int _result = (expr); * * * * * * * * * * * \
> * * if (_result < 0) { stmts; return _result; } * * *\
> * * _result; * * * * * * * * * * * * * * * * * *\
> * })
>
> </code>
>
> (this is from RabbitMQ's C client code, BTW)
>
> One use of this macro is:
>
> AMQP_CHECK_RESULT_CLEANUP(amqp_decode_field_value( encoded,
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * pool,
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * &entry->value,
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * &offset),
> * * * * * * * * * * * * * * * * * * * * * * free(entries));
>
> This should expand into:
>
> * {
> * * int _result = ( amqp_decode_field_value(encoded,
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * pool,
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * &entry->value,
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * &offset) );
> * * if ( _result < 0 )
> * * {
> * * * free(entries);
> * * * return _result;
> * * }
>
> * * _result;
> * }
>
> On Gnu C this works (although, now that I am writing this, I don't seem
> to get what the lonely _result; actually does !!!).
>
> MS C barks on Syntax Error "{" illegal.
>
> Now, well, ok, macrology is sometimes spooky, but why does GNU C simply
> accepts this of why does MS C not want to swallow it ?
>
> Thanks for any hints!!
>
> Frank


Here is one, Frank: check for hidden spaces after the escape
continuations...they cause an error in Microsoft C.
 
Reply With Quote
 
 
 
 
James
Guest
Posts: n/a
 
      06-03-2010
"spinoza1111" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Jun 3, 10:52 pm, Frank GOENNINGER <(E-Mail Removed)> wrote:
> > Hi all:
> >
> > Having been coding for more than 20 years in various Unix/Linux/OS X
> > flavors I am now challenged to work on Windows.
> >
> > I have:

[...]
> > MS C barks on Syntax Error "{" illegal.
> >
> > Now, well, ok, macrology is sometimes spooky, but why does GNU C simply
> > accepts this of why does MS C not want to swallow it ?
> >
> > Thanks for any hints!!


> Here is one, Frank: check for hidden spaces after the escape
> continuations...they cause an error in Microsoft C.


I don't think MSVC understands the GCC extension.

 
Reply With Quote
 
 
 
 
spinoza1111
Guest
Posts: n/a
 
      06-04-2010
On Jun 3, 11:50*pm, Richard Heathfield <(E-Mail Removed)> wrote:
> spinoza1111wrote:
> > On Jun 3, 10:52 pm, Frank GOENNINGER <(E-Mail Removed)> wrote:

>
> <snip>
>
> >> MS C barks on Syntax Error "{" illegal.

>
> >> Now, well, ok, macrology is sometimes spooky, but why does GNU C simply
> >> accepts this of why does MS C not want to swallow it ?

>
> >> Thanks for any hints!!

>
> >> Frank

>
> > Here is one, Frank: check for hidden spaces after the escape
> > continuations...they cause an error in Microsoft C.

>
> Nice try, actually, because that *could* have been the reason.
>
> James and Jacob have already reported the real reason - gcc offers quite
> a few extensions to the capability of the C preprocessor, of which
> assigning a value to a braced expression in a macro is one, and it is
> one which MSVC does not support (and neither is there any particular
> reason why it should).
>
> Nevertheless, when one uses the line continuation character to extend a
> macro over more than one physical line, there *is* a danger - not just
> under Microsoft C but under any implementation - that a stray space or
> tab could sneak its way after the \, breaking the line-continuation
> functionality.
>
> It was a great answer, in fact. Unfortunately, in this case you picked
> the wrong question.
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within


It was a great answer, since it took ten seconds on the Lamma Island
ferry. And I'm obliged to you, you swine, for confirming my low
attitude towards C. It's infantile to require the programmer to NOT
put spaces after the continuation UNLESS there's a reason, and I can't
think of one.

Perhaps escape blank means something somewhere?

I'm certain you won't pass up the opportunity to inform me of this
rather useless bit of information.
 
Reply With Quote
 
Tom St Denis
Guest
Posts: n/a
 
      06-04-2010
On Jun 4, 1:10*pm, Walter Banks <(E-Mail Removed)> wrote:
> spinoza1111 wrote:
> > It was a great answer, since it took ten seconds on the Lamma Island
> > ferry. And I'm obliged to you, you swine, for confirming my low
> > attitude towards C. It's infantile to require the programmer to NOT
> > put spaces after the continuation UNLESS there's a reason, and I can't
> > think of one.

>
> escape newline = continuation.
>
> \n (new line) Moves the active position to the initial position of the
> next line


OH SNAP.

Tom
 
Reply With Quote
 
blmblm@myrealbox.com
Guest
Posts: n/a
 
      06-06-2010
In article <(E-Mail Removed)>,
Walter Banks <(E-Mail Removed)> wrote:
>
>
> spinoza1111 wrote:
>
> > It was a great answer, since it took ten seconds on the Lamma Island
> > ferry. And I'm obliged to you, you swine, for confirming my low
> > attitude towards C. It's infantile to require the programmer to NOT
> > put spaces after the continuation UNLESS there's a reason, and I can't
> > think of one.

>


Well, I can, and I *think* it's the reason Walter's getting at here:

>
> escape newline = continuation.
>
> \n (new line) Moves the active position to the initial position of the
> next line
>


Normally "\" as an escape character means that the character
immediately after the "\" is to be interpreted differently from
how it's normally interpreted. I can understand how having a
different rule if what comes after the "\" is one or more spaces
followed by a newline might be in some ways easier, but it *would*
be a different rule, no?

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      06-11-2010
Walter Banks <(E-Mail Removed)> writes:
> "(E-Mail Removed)" wrote:
> > Walter Banks <(E-Mail Removed)> wrote:
> > > escape newline = continuation.
> > >
> > > \n (new line) Moves the active position to the initial position of the
> > > next line
> > >

> >
> > Normally "\" as an escape character means that the character
> > immediately after the "\" is to be interpreted differently from
> > how it's normally interpreted. I can understand how having a
> > different rule if what comes after the "\" is one or more spaces
> > followed by a newline might be in some ways easier, but it *would*
> > be a different rule, no?

>
> There are some compilers that strip trailing spaces on source
> lines. This makes it look like \ <space> <newline> works.


However, these are not C compilers. C is not translated that way;
The standard says so.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      06-11-2010
Walter Banks <(E-Mail Removed)> writes:
<snip>
> Alternatively can anyone devise a program that would detect
> trailing space stripping?


I think this does C89 program does (it is rather contrived):

#include <stdlib.h>

int x = /**\
/EXIT_FAILURE/**/;

int main(void) { return x; }

with an optional space in the obvious place (after the \).

--
Ben.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-11-2010
Richard Heathfield <(E-Mail Removed)> writes:
> Walter Banks wrote:

[...]
> > Only the last backslash on
>> any physical source line shall be eligible for being part
>> of such a splice.

>
> This is redundant.


That was my thought as well, but I presume the authors had something in
mind when they wrote that sentence.

The only case I can think of where it makes a difference is an
implementation where physical source lines are terminated by something
other than a new-line character but can contain embedded new-line
characters. Assuming that physical source lines are terminated by '@',
you could have a physical source line like this, where \n represents
a new-line character:

x = 42; \\n /* a comment */ \@

After translation phase 1, we have:

x = 42; \\n /* a comment */ \\n

which makes two logical source lines. The first backslash is
immediately followed by a new-line, so it would normally be spliced,
but it's not the last backslash on the physical source line, so
it's a syntax error.

That might make some sense as a way to flag a certain kind of very
obscure error, but if the second backslash is removed then the first one
*is* the last backslash on the physical source line so it will be
spliced.

So what is the real purpose of the "Only the last backslash" rule?

> <snip>
>
>> Byte Craft's compilers strip trailing white space.

>
> I think that renders those compilers non-conforming in that regard. In
> this case, that may well be a price you're prepared to pay. Is there at
> least some way of turning the stripping off?


Trailing whitespace cannot be stripped in translation phase 2, but I
believe it can be stripped in translation phase 1.

For example, think about a system where lines in text files are
fixed-length with trailing spaces. On such a system, it would be
unpleasant to require line-splicing backslashes to appear in the
last column of the physical line.

Can anyone think of a case where stripping all trailing whitespace
in phase 1 would either break or change the meaning of a valid
translation unit? I can't. The only drawback is that it means
a file that would be rejected by other compilers could compile
without any diagnostics.

If the standard were modified to require all trailing whitespace
to be removed in translation phase 1, would that break anything?

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-11-2010
Ben Bacarisse <(E-Mail Removed)> writes:
> Walter Banks <(E-Mail Removed)> writes:
> <snip>
>> Alternatively can anyone devise a program that would detect
>> trailing space stripping?

>
> I think this does C89 program does (it is rather contrived):
>
> #include <stdlib.h>
>
> int x = /**\
> /EXIT_FAILURE/**/;
>
> int main(void) { return x; }
>
> with an optional space in the obvious place (after the \).


If the lines are not spliced, the EXIT_FAILURE token is
commented out, and the final result is

int x = ;

which is a syntax error.

I think this should do the job:

#include <stdlib.h>

int x = /**\
/EXIT_FAILURE/**/ + 0;

int main(void) { return x; }

If the lines are spliced, then we have (adding whitespace):

int x = /**/ EXIT_FAILURE /**/ + 0;

and removing comments:

int x = EXIT_FAILURE + 0;

If the lines are not spliced, then we have a single comment:

int x = /**\\n/EXIT_FAILURE/**/ + 0;

or:

int x = +0;

(I think gcc gets this wrong; when I add a space after the backslash,
I still get "int x = 1 + 0;" after preprocessing. Or gcc gets it
right and I'm misunderstanding something.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      06-11-2010
Keith Thompson <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>> Walter Banks <(E-Mail Removed)> writes:
>> <snip>
>>> Alternatively can anyone devise a program that would detect
>>> trailing space stripping?

>>
>> I think this does C89 program does (it is rather contrived):
>>
>> #include <stdlib.h>
>>
>> int x = /**\
>> /EXIT_FAILURE/**/;
>>
>> int main(void) { return x; }
>>
>> with an optional space in the obvious place (after the \).

>
> If the lines are not spliced, the EXIT_FAILURE token is
> commented out, and the final result is
>
> int x = ;
>
> which is a syntax error.


Yes. That'll teach me to edit just before posting! I started with

int x = /**\
/0/**/+1;

and a printf in main. My *plan* was to edit this to:

int x /**\
/=EXIT_FAILURE/**/;

to use static zero initialisation.

<snip>
> (I think gcc gets this wrong; when I add a space after the backslash,
> I still get "int x = 1 + 0;" after preprocessing. Or gcc gets it
> right and I'm misunderstanding something.)


Interesting, gcc behaves differently depending on where the trailing
scale is. If it is not in a comment, you get a warning:

warning: backslash and newline separated by space

but not for the example above. In both cases gcc strips the trailing
space.

--
Ben.
 
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
microsoft.public.certification, microsoft.public.cert.exam.mcsa, microsoft.public.cert.exam.mcad, microsoft.public.cert.exam.mcse, microsoft.public.cert.exam.mcsd realexxams@yahoo.com Microsoft Certification 0 05-10-2006 02:35 PM
Re: Any non-GNU compilers? sick of GNU copylefts Markus Elfring C++ 2 02-23-2005 10:24 PM
R e: 1 day gnu, whole life gnu? Peter Java 17 01-13-2005 03:32 PM
1 day gnu, whole life gnu? Peter Java 3 01-10-2005 02:26 PM
microsoft.public.dotnet.faqs,microsoft.public.dotnet.framework,microsoft.public.dotnet.framework.windowsforms,microsoft.public.dotnet.general,microsoft.public.dotnet.languages.vb Charles A. Lackman ASP .Net 1 12-08-2004 07:08 PM



Advertisments