This is the mail archive of the gcc@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]

Fwd: cc-mode adds newlines


forwarding since few people actually read gcc-bugs@.

Thanks,
Andrew Pinski

Begin forwarded message:

From: Alan Mackenzie <acm@muc.de>
Date: November 25, 2004 3:35:07 PM EST
To: Richard Stallman <rms@gnu.org>, bug-gcc@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: cc-mode adds newlines

Hi, Richard, Hi, Emacs developers, Hi, gcc maintainers!

On Wed, 24 Nov 2004, Richard Stallman wrote:

[Subject: gcc's acceptance of string constants which straddle lines.]
Accepting such strings is a violation of the C++ standard, I think. I'll
need to complain about this to GCC. Possibly, I'll not be the first.

We do not "violate" the C++ standard, we diverge from it.  We do not
regard standards as authorities.  We make our own decisions.

OK. That's fine by me, but .....


The situation which bit me was this:  In our embedded system, commands
get sent from device to device as strings of ASCII, a fairly normal
thing.

One particular command string was, in essence, coded thus:

const char *command =
    "aaaa
     bbbb" ;

which normally compiles to "aaaa<LF>     bbbb".  The receiving device
ignores the white space.

However, due to a mixup with proprietory version control systems and
editors, this source file somehow got to the build process with
"proprietory" line terminators. gcc compiled the file without complaint
(on QNX, a proprietory Posix system), but the command string ended up as


"aaaa<CR><LF> bbbb".

To the receiving device, the <CR> meant something like "do not process
the rest of this command". To track the resulting bug down took about 40
hours of work, all told.


This is, I think, the reason why the C and C++ standards don't allow
strings to straddle lines: the meaning of a source file can change with
the EOL convention.


Now, I like proprietory file formats almost as little as you do, and over
the decades, in projects like ours, they must have wasted untold billions
of dollars, pounds, Marks, Yen, Francs, ...., not to mention trillions of
Lira and Pesetas ;-).


It would have been nice to have got at least a warning message here. Of
course, the Right Thing is for me to put the appropriate option (perhaps
-traditional-cpp?) into the build scripts. The solution I actually
adopted was to purge all such strings from the source files (all ~2200 of
them - it's a very slackly written program :-( It took me ~half a day to
write a regular expression to find them). However, those 40 hours of
work are lost forever :-(.


But I _do_ understand the need for having strings straddling lines, too.
It's would be a pain in the donkey to have to end every line of, for
example, the doc string in a DEFUN macro with ....\n", and things like
that. And I _do_ understand that it's desirable, sometimes, to compile
those strings with the target OS's EOL convention.


Complain if you wish, but I will not agree to the absurd limitation of
string constants to a single line.

By "complain", I meant simply to draw my experiences to the attention of
the gcc maintainers, and ask them to consider, perhaps, whether the gcc
options (or their defaults) might be modified in some way so as to help
other projects avoid falling into the same trap as mine did, whilst at
the same time not inconveniencing those who positively need such strings.


I was not proposing throwing some sort of temper fit.  I think you know
me better than that by now.  ;-)

So, gcc people: is there a way?

Thanks in advance!

--
Alan Mackenzie (Munich, Germany)



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