Which preprocessor is correct?

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

If you have:
#define errno retrieve_errno_ func()

#define SUBSYSTEM_INCLU DE(subsystem, file) <subsystem/include/file>
then what should happen when you do:
#include SUBSYSTEM_INCLU DE(posix, errno.h)

gcc2.95 pre-processes as intended, to:

#include <posix/include/errno.h>

gcc3.4 preprocessed to:

#include <posix/include/retrueve_errno_ func()>

My guess is that gcc3.4 was the correct one, even though it didn't
produce the intended result.

[vippstar]

On Jul 24, 4:03 pm, Tomás Ó hÉilidhe <t...@lavabit.c omwrote:

If you have:

#define errno retrieve_errno_ func()

unless retrieve_errno_ func is a function-like macro expanding to a
modifiable lvalue, this is wrong.

[fnegroni]

On Jul 24, 4:18*pm, vipps...@gmail. com wrote:

On Jul 24, 4:03 pm, Tomás Ó hÉilidhe <t...@lavabit.c omwrote:If you have:

* *#define errno retrieve_errno_ func()

unless retrieve_errno_ func is a function-like macro expanding to a
modifiable lvalue, this is wrong.

Why?

[Johannes Bauer]

fnegroni schrieb:

On Jul 24, 4:18 pm, vipps...@gmail. com wrote:

>On Jul 24, 4:03 pm, Tomás Ó hÉilidhe <t...@lavabit.c omwrote:If you have:

>> #define errno retrieve_errno_ func()

unless retrieve_errno_ func is a function-like macro expanding to a
modifiable lvalue, this is wrong.

Why?

Because errno has to be lvalue-modifyable.

errno = 0;

will not work when errno expands to

foobar() = 0;

Regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electron ics <47************ ***********@new s.freenet.de>

[Johannes Bauer]

fnegroni schrieb:

>>Why?

Because errno has to be lvalue-modifyable.

errno = 0;

will not work when errno expands to

foobar() = 0;

And from the incomplete code snippet from the OP, what gave you that
information?

Nothing - but *you* asked why it cannot be a modifyable lvalue.

*retrieve_errno _func_impl() = 2;

Dereferencing any non-const, non-void pointer yields a modifyable
lvalue, which is exactly what I said.

Regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electron ics <47************ ***********@new s.freenet.de>

[fnegroni]

On Jul 24, 5:39*pm, Johannes Bauer <dfnsonfsdu...@ gmx.dewrote:

fnegroni schrieb:

On Jul 24, 4:18 pm, vipps...@gmail. com wrote:

On Jul 24, 4:03 pm, Tomás Ó hÉilidhe <t...@lavabit.c omwrote:If you have:

>* *#define errno retrieve_errno_ func()
unless retrieve_errno_ func is a function-like macro expanding to a
modifiable lvalue, this is wrong.

Why?

Because errno has to be lvalue-modifyable.

errno = 0;

will not work when errno expands to

foobar() = 0;

And from the incomplete code snippet from the OP, what gave you that
information?

I can very easily write this complete example, using the OP's code
snippet:

#define retrieve_errno_ func() *retrieve_errno _func_impl()

#define errno retrieve_errno_ func()

int myerrno;

int *retrieve_errno _func_impl()
{
return &myerrno;
}

int
main(void)
{
errno = 2;
return 0;
}

Which will be preprocessed into:

int myerrno;

int *retrieve_errno _func_impl()
{
return &myerrno;
}

int
main(void)
{
*retrieve_errno _func_impl() = 2;
return 0;
}

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

Please focus on the original topic of which preprocessor was correct.

[Eric Sosman]

Tomás Ó hÉilidhe wrote:

If you have:
#define errno retrieve_errno_ func()

#define SUBSYSTEM_INCLU DE(subsystem, file) <subsystem/include/file>
then what should happen when you do:
#include SUBSYSTEM_INCLU DE(posix, errno.h)

gcc2.95 pre-processes as intended, to:

#include <posix/include/errno.h>

gcc3.4 preprocessed to:

#include <posix/include/retrueve_errno_ func()>

My guess is that gcc3.4 was the correct one, even though it didn't
produce the intended result.

What you've shown for gcc3.4 cannot possibly be right, because
an "i" has somehow transmuted to a "u" and a ".h" has vanished.
(I *wish* people would learn to copy-and-paste instead of polluting
their posts with typos ...)

But if the "u" is turned back to "i" and the ".h" is restored,
I believe gcc3.4 is correct (6.10.2p4). Note that

#include < posix / include / retrieve_errno_ func ( ) . h >

would also be correct, because macro replacement works with tokens
(actually "preprocess ing tokens"), not with text. You'll also note
that the way all these pp-tokens get combined into a single header
name is implementation-defined, hence a threat to portability.

--
Er*********@sun .com

[Peter Nilsson]

Eric Sosman wrote:

Tom�s � h�ilidhe wrote:

If you have:

#define errno retrieve_errno_ func()

#define SUBSYSTEM_INCLU DE(subsystem, file) <subsystem/include/file>

then what should happen when you do:

#include SUBSYSTEM_INCLU DE(posix, errno.h)

gcc2.95 pre-processes as intended, to:

#include <posix/include/errno.h>

gcc3.4 preprocessed to:

#include <posix/include/retrueve_errno_ func()>

My guess is that gcc3.4 was the correct one, even though it didn't
produce the intended result.

What you've shown for gcc3.4 cannot possibly be right, because
an "i" has somehow transmuted to a "u" and a ".h" has vanished.
(I *wish* people would learn to copy-and-paste instead of polluting
their posts with typos ...)

But if the "u" is turned back to "i" and the ".h" is restored,
I believe gcc3.4 is correct (6.10.2p4). Note that

#include < posix / include / retrieve_errno_ func ( ) . h >

would also be correct, because macro replacement works with tokens
(actually "preprocess ing tokens"), not with text.

Which is why the "" form, generated via #, is better IMO. The rules
for
whitespace are much clearer.

You'll also note
that the way all these pp-tokens get combined into a single header
name is implementation-defined, hence a threat to portability.

True, but the #include pp-tokens directive was not exactly designed
with maximal portability in mind! Certainly no more than (say) the
system() function was.

--
Peter

[vippstar]

On Jul 24, 11:35 pm, fnegroni <f.e.negr...@go oglemail.comwro te:

On Jul 24, 5:39 pm, Johannes Bauer <dfnsonfsdu...@ gmx.dewrote:

fnegroni schrieb:

On Jul 24, 4:18 pm, vipps...@gmail. com wrote:
>On Jul 24, 4:03 pm, Tomás Ó hÉilidhe <t...@lavabit.c omwrote:If you have:

>> #define errno retrieve_errno_ func()
>unless retrieve_errno_ func is a function-like macro expanding to a
>modifiable lvalue, this is wrong.

Why?

Because errno has to be lvalue-modifyable.

errno = 0;

will not work when errno expands to

foobar() = 0;

And from the incomplete code snippet from the OP, what gave you that
information?

I can very easily write this complete example, using the OP's code
snippet:

#define retrieve_errno_ func() *retrieve_errno _func_impl()

And retrieve_errno_ func() would be a function-like macro expanding to
a modifiable lvalue.
Notice my words:

vippstar said:

>unless retrieve_errno_ func is a function-like macro expanding to a
>modifiable lvalue, this is wrong.