Re: c/9762: Address of 'char' is incorrect.

2003-02-19 Thread Neil Booth
[EMAIL PROTECTED] wrote:- > In the example below, '&a' is the address of a local copy of 'a' not of > 'a'. > if the type of 'a' is changed to int, it works as expected. Works as who expected? Where is the bug? Please quote which part of the C standard is violated. You got an addre

Re: preprocessor/8524: _Pragma within macros is improperly expanded

2002-11-18 Thread Neil Booth
Neil Booth wrote:- > I think this fixes it for good. I'm applying this to 3.3, and 3.2.2 > when it arrives. > > Neil. > > PR preprocessor/8524 > * cpplib.c (run_directive): Remove previous kludge to _Pragma. > Add a new one in its

Re: preprocessor/8524: _Pragma within macros is improperly expanded

2002-11-18 Thread Neil Booth
I think this fixes it for good. I'm applying this to 3.3, and 3.2.2 when it arrives. Neil. PR preprocessor/8524 * cpplib.c (run_directive): Remove previous kludge to _Pragma. Add a new one in its place, which hopefully works. (skip_rest_of_line): Change test for b

Bug#157416: _Pragma() from macros - bug

2002-09-06 Thread Neil Booth
Steve Ellcey wrote:- > > I am confused by the new test gcc.dg/cpp/_Pragma4.c that was added by > this patch and wonder if I am missing something or if there is a typo in > the test. > > I believe the test is searching for the string '#pragma bat' (bat with a > t) to see if the tests succeeded, b

Bug#157416: _Pragma() from macros - bug

2002-09-03 Thread Neil Booth
Zack Weinberg wrote:- > This was reported to the Debian bug-tracking system: > > $ cat foo.c > _Pragma("foo"); int y; > #define FOO _Pragma("foo"); int x; > FOO > [EMAIL PROTECTED]:~$ cpp-3.2 foo.c > # 1 "foo.c" > # 1 "" > # 1 "" > # 1 "foo.c" > > # 1 "foo.c" > #pragma foo > # 1 "foo.c" >

Bug#157416: _Pragma() from macros - bug

2002-08-30 Thread Neil Booth
Zack Weinberg wrote:- > This was reported to the Debian bug-tracking system: > > $ cat foo.c > _Pragma("foo"); int y; > #define FOO _Pragma("foo"); int x; > FOO > [EMAIL PROTECTED]:~$ cpp-3.2 foo.c > # 1 "foo.c" > # 1 "" > # 1 "" > # 1 "foo.c" > > # 1 "foo.c" > #pragma foo > # 1 "foo.c" >

Re: preprocessor/7558: preprocessor option -MM has change semantic

2002-08-11 Thread Neil Booth
Martin v. Loewis wrote:- > Neil Booth <[EMAIL PROTECTED]> writes: > > > If it's a system header, why are you lying to the compiler? > > I'm not lying, I use You've not told the compiler it's a system header, so it doesn't think it is. Let me see what Zack thinks. Neil.

Re: preprocessor/7558: preprocessor option -MM has change semantic

2002-08-11 Thread Neil Booth
Martin, If it's a system header, why are you lying to the compiler? Maybe a real-life example and not "a.h" would help. Neil.

Re: preprocessor/7558: preprocessor option -MM has change semantic

2002-08-10 Thread Neil Booth
[EMAIL PROTECTED] wrote:- > >Description: > In gcc 3.1, -MM prints dependencies even to files included with > angle brackets (), if those are found through -I options. > This behaviour is unintuitive and a change from earlier versions. Why are you using <> brackets? Why is #inc

Re: preprocessor/2881: code inside "#if 0" generates warnings with -pedantic

2001-05-20 Thread Neil Booth
Markus F.X.J. Oberhumer wrote:- > #if 0 > // int bar =3D 1; > #endif Zack, what's you opinion of this? Whether we accept the // can affect tokenisation, which must still be valid in skipped blocks. In other words, acceptance of #if 0 // ' #endif depends upon whether we accept //. I'm tempted