«

On Jun 3, 10:52*pm, Frank GOENNINGER <dg1...@googlemail.com> 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.

"spinoza1111" <> wrote in message
news:8b3c99ea-9bf6-4f62-80a5-...
On Jun 3, 10:52 pm, Frank GOENNINGER <dg1...@googlemail.com> 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.

On Jun 3, 11:50*pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> spinoza1111wrote:
> > On Jun 3, 10:52 pm, Frank GOENNINGER <dg1...@googlemail.com> 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.

On Jun 4, 1:10*pm, Walter Banks <wal...@bytecraft.com> 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

In article <>,
Walter Banks <> 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.

Walter Banks <> writes:
> "" wrote:
> > Walter Banks <> 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

Walter Banks <> 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.

Richard Heathfield <> 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) kst- <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"

Ben Bacarisse <> writes:
> Walter Banks <> 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) kst- <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"

Keith Thompson <kst-> writes:

> Ben Bacarisse <> writes:
>> Walter Banks <> 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.