On Thu, Nov 7, 2013 at 10:44 AM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
> On Thu, Nov 7, 2013 at 8:16 AM, Andrey Smirnov
> <andrey.smirnov@xxxxxxxxxxx> wrote:
>>
>> I recently stumbled upon what for me was surprising behavior of GCC. I
>> was writing some code on my Linux machine and was using data from a
>> data dump text file that had DOS line endings. As a commentary to one
>> of my functions I copied an excerpt from the dump file and
>> inadvertently added some DOS line endings to my source file. So what I
>> discovered is that, after that, GCC would output incorrect diagnostic
>> information in which it would think that an error/warning was present
>> several lines below its actual location.
>>
>> The following example(^M denotes DOS line ending) on gcc-4.8.0
>> compiled with: "gcc test.c -o test.o"
>>
>> struct a {
>> int c;
>> void (*f) (void);
>> };
>>
>> void foo (void)
>> {
>> /* ^M */
>> }
>>
>> struct a A = {
>> .c = foo,
>> .f = foo,
>> };
>>
>> would cause GCC to output:
>>
>> test.c:14:9: warning: initialization makes integer from pointer
>> without a cast [enabled by default]
>> .f = foo,
>> ^
>>
>> whereas with ^M removed it would say:
>>
>> test.c:13:9: warning: initialization makes integer from pointer
>> without a cast [enabled by default]
>> .c = foo,
>> ^
>>
>> Is this an expected behavior that I was not aware due to my ignorance?
>
>
> GCC treats a bare \r in a program as though it were an old MacOS file,
> where \r ends a line. So I think this is simply a disagreement
> between what you expect and what GCC expects.
>
> I don't think there is any right answer here.
>
> Ian
Correct me if I'm wrong, but I believe it's not an issue of the line
number it is complaining about, but rather that it indicates the wrong
code is at fault? The actual error is that you're assigning a
function pointer to an integer, but with the ^M in comments, despite
stating the correct type of error, gcc indicates ".f = foo" is the
error instead of ".c = foo".
I just tested with gcc 4.8.2, and this still seems to be the case.
Brian
