This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Mixed line endings(DOS/Unix) in the source file
- From: Ian Lance Taylor <iant at google dot com>
- To: Andrey Smirnov <andrey dot smirnov at synapse dot com>
- Cc: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Thu, 7 Nov 2013 10:44:51 -0800
- Subject: Re: Mixed line endings(DOS/Unix) in the source file
- Authentication-results: sourceware.org; auth=none
- References: <CAMRrfq4qoLXqFp9Tj_roNzf-Y585mHKT3j-zfUv+Q_2w9BGzvw at mail dot gmail dot com>
On Thu, Nov 7, 2013 at 8:16 AM, Andrey Smirnov
<andrey.smirnov@synapse.com> 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