[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pcc-list
Subject:    Re: [Pcc] macro substitution in _Pragma() string
From:       Anders Magnusson <ragge () ludd ! ltu ! se>
Date:       2015-10-20 18:31:59
Message-ID: 5626889F.1080602 () ludd ! ltu ! se
[Download RAW message or body]

Den 2015-10-20 kl. 20:13, skrev Iain Hibbert:
> On Tue, 20 Oct 2015, Anders Magnusson wrote:
>
>> Den 2015-10-19 kl. 21:34, skrev Iain Hibbert:
>>> Hi
>>>
>>> the following code example
>>>
>>> #define FOO	0x004
>>>
>>> #define __foo	_Pragma("FOO")
>>>
>>> __foo int foo;
>>>
>>> when compiled with the preprocessor, results in
>>>
>>> # 1 "test.c"
>>>
>>> #pragma 0x004
>>> # 5 "test.c"
>>>    int foo;
>>>
>>> it seems that the FOO in the _Pragma() argument has been expanded during
>>> the macro substitution, which I don't think it should have been..
>> This seems to be an interesting situation...
>> 6.10.9 says that _Pragma("FOO") should be put back to translation phase
>> 3 as #pragma FOO 6.10.6 says that the compiler is allowed to macro
>> expand this type of pragma but not required to.
> However, 6.10.6 says that it is not allowed to expand in the case of STDC
> before macro expansion (no word on what happens if macro expansion results
> in STDC) .. So it seems then that if pcc were to do macro expansion with
> these tokens, then it can only do it after checking for STDC .. which
> would seem to make the easy option be to just not bother with that..?
>
>> There are programs that expect pragmas to to be macro expanded, hence it is
>> added.
> well, that could certainly be a problem..  on which platform though?  it
> seems that GCC and Clang both on NetBSD don't expand the example I gave,
> and neither do they expand a basic
>
>    #pragma FOO
>
> statement
Hm, after some thoughts I think you have a point here, so I have fixed 
cpp not
to do this expansion.  Should not give any side effects.

-- Ragge


>
>> So, I do not really have an idea here what to do...? :-)
> Well me neither.. for the following example
>
> #define FOO foo
>
> _Pragma("FOO")
> #pragma FOO
>
> there seem to be four options
>
> 1.
> 	#pragma FOO
> 	#pragma FOO
>
>      this is the simple and consistent never-expand case, which is
>      compatible with other free compilers on NetBSD at least
>
> 2.
> 	#pragma FOO
> 	#pragma foo
>
>      slightly inconsistent but not unsurprising, as the contents of a
>      string literal are not normally expanded
>
> 3.
> 	#pragma foo
> 	#pragma FOO
>
>      the current situation but I can't see anything good about it :)
>
> 4.
> 	#pragma foo
> 	#pragma foo
>
>      the consistent always-expand (except for STDC) case which may be
>      required by some code
>
>
> I think that if code truly expects the last case, then it should be
> provided for.. but if it is only code on a particular platform (eg lets
> say because the compiler for FooOS always did it that way) then it could
> be a compile option enabled for that platform.
>
> The issue came about for me because (in NetBSD) usr.bin/mail/cmd2.c
> includes a file which defines GCC before including <util.h> which contains
> a __BEGIN_DECLS, which translates to a _Pragma("GCC") statement. I don't
> think this has changed in recent times though, or if this occurs anywhere
> else in the sources.
>
> iain
> _______________________________________________
> Pcc mailing list
> Pcc@lists.ludd.ltu.se
> https://lists.ludd.ltu.se/cgi-bin/mailman/listinfo/pcc

_______________________________________________
Pcc mailing list
Pcc@lists.ludd.ltu.se
https://lists.ludd.ltu.se/cgi-bin/mailman/listinfo/pcc
[prev in list] [next in list] [prev in thread] [next in thread]