Which preprocessor is correct?

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

If you have:
#define errno retrieve_errno_func()

#define SUBSYSTEM_INCLUDE(subsystem, file) <subsystem/include/file>
then what should happen when you do:
#include SUBSYSTEM_INCLUDE(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 <[e-mail]:

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, [e-mail] wrote:

On Jul 24, 4:03 pm, Tomás Ó hÉilidhe <[e-mail]: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, [e-mail] wrote:

>On Jul 24, 4:03 pm, Tomás Ó hÉilidhe <[e-mail]: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.electronics <47***********************@news.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.electronics <47***********************@news.freenet.de>

[fnegroni]

On Jul 24, 5:39*pm, Johannes Bauer <[e-mail]:

fnegroni schrieb:

On Jul 24, 4:18 pm, [e-mail] wrote:

On Jul 24, 4:03 pm, Tomás Ó hÉilidhe <[e-mail]: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_INCLUDE(subsystem, file) <subsystem/include/file>
then what should happen when you do:
#include SUBSYSTEM_INCLUDE(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 "preprocessing 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_INCLUDE(subsystem, file) <subsystem/include/file>

then what should happen when you do:

#include SUBSYSTEM_INCLUDE(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 "preprocessing 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 <[e-mail]:

On Jul 24, 5:39 pm, Johannes Bauer <[e-mail]:

fnegroni schrieb:

On Jul 24, 4:18 pm, [e-mail] wrote:
>On Jul 24, 4:03 pm, Tomás Ó hÉilidhe <[e-mail]: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.

[Old Wolf]

On 25 Jul, 01:03, Tomás Ó hÉilidhe <[e-mail]:

If you have:

#define errno retrieve_errno_func()

This causes undefined behaviour if errno.h
is included, BTW.

[Johannes Bauer]

Tomás Ó hÉilidhe schrieb:

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

Why should we? Although the topic has changed, the discourse is still
topical in c.l.c. - therefore I see no reason why one should not
digress. Most *really* interesting discussions evolve from something
which was not the primary question.

So unless I get paid for writing in c.l.c. I feel free to comment on
whatever appears to interest me :-)

Kind 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.electronics <47***********************@news.freenet.de>

[Giacomo Catenazzi]

Eric Sosman wrote:

Tomás Ó hÉilidhe wrote:

>If you have:
#define errno retrieve_errno_func()

#define SUBSYSTEM_INCLUDE(subsystem, file) <subsystem/include/file>
then what should happen when you do:
#include SUBSYSTEM_INCLUDE(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 "preprocessing 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.

I don't agree. From section 6.4 and 6.4.7, the header-name is a
indivisible token, so it should not be splitt and substituted.

ciao
cate

[Eric Sosman]

Giacomo Catenazzi wrote:

Eric Sosman wrote:

>Tomás Ó hÉilidhe wrote:

>>If you have:
#define errno retrieve_errno_func()

#define SUBSYSTEM_INCLUDE(subsystem, file) <subsystem/include/file>
then what should happen when you do:
#include SUBSYSTEM_INCLUDE(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 "preprocessing 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.

I don't agree. From section 6.4 and 6.4.7, the header-name is a
indivisible token, so it should not be splitt and substituted.

The line

#include SUBSYSTEM_INCLUDE(posix, errno.h)

does not contain a header-name token. A header-name has one of
the two forms

< h-char-sequence >
or
" q-char-sequence "

.... and the given line matches neither of these. So neither of
6.10.2p2 nor 6.10.2p3 applies, and we must turn to 6.10.2p4 to
describe how the line is processed. There we find that the
line is read as

# include pp-tokens new-line

.... and that the list of pp-tokens is subject to macro replacement.
After replacement, the pp-tokens are reassembled into one of the two
header-name forms in an implementation-defined way.

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