This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Mac line ending at EOF AND no newline warnings


Devang Patel <dpatel@apple.com> writes:

> On Feb 17, 2005, at 4:15 PM, Zack Weinberg wrote:
>
>> Devang Patel <dpatel@apple.com> writes:
>>> GCC emits no-newline warning when it sees Mac line ending
>>> at the end of file. This is because _cpp_convert_input()
>>> automatically inserts '\n' at the end of buffer. This
>>> confuses _cpp_clean_line() when it sees '\r' and '\n' together.
>> I would rather this was dealt with in _cpp_convert_input - have it
>> check for a \r at EOF and not stick in an extra \n in that case.
>
>
> I bootstrapped and tested following patch overnight. OK for mainline?

This is still not quite right.  

> !   if (to.text[to.len - 1] != '\r')
> !     to.text[to.len] = '\n';
> !
>      *st_size = to.len;

The character at to.text[to.len] is going to get looked at, so it
needs to be initialized.  I didn't think of this earlier, and you
probably got away with it because you had a nul or something equally
innocuous there.  Also, you need a comment explaining what's going on.
I would suggest:

  /* If the file is using old-school Mac line endings (\r only),
     terminate with another \r, not an \n, so that we do not mistake
     the \r\n sequence for a single DOS line ending and erroneously
     issue the "No newline at end of file" diagnostic.  */
  if (to.text[to.len - 1] == '\r')
    to.text[to.len] = '\r';
  else
    to.text[to.len] = '\n';

Also make sure a comment appears in Wmac-eol-at-eof.c stating clearly
that this file uses Mac-style line endings, and make sure CVS does not
mangle the file when you commit it.

Approved with these changes.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]