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]

Re: Removing -frwitable-strings


On Fri, 19 Dec 2003, Syd Polk wrote:

> Make -Wwrite-strings on by default. Otherwise, people who port to gcc 

The trouble is, it warns for a great deal of reasonably clean
standards-conforming code, and the changes required to fix those warnings
are more wide-ranging than for -Wall (which it might be more reasonable to
enable by default).  In rare cases it may also *remove* diagnostics
required by the standard as a side effect of giving string literals a
different type from that the C standard requires.

> for the first time (like me when this happened) won't see it. To be 
> honest, I don't know where this "Incompatibilities" section is. There 
> is tons of documentation on gcc, so much as to be daunting. At the time 

What I do hope is that people starting to use GCC would read through at
least the documentation of warning options and add all the options that
sound like they might be useful to their Makefiles (they can always remove
some later once experience tells them which options are useful), not try
to use a complicated tool without first trying for an overall grasp of how
to do so.  Alternatively, having watched builds of software (such as GCC) 
which use lots of warning options themselves may suggest options it would 
be worth trying, or at least understanding what they do.

"Incompatibilities" is under "Trouble" in the GCC manual, and I'd hope
that a section "If you have trouble using GCC" is an early place people
having trouble would visit.  (Unfortunately, a lot of that chapter is
rather old; and while the section is described as "GCC is incompatible
with traditional C" in the menu, some of the issues listed such as
readonly strings and preprocessing numbers still come up for people who
may never have known anything of pre-standard C.)

Improving the manual so that people find the information that is there
when they need it (and in particular, don't report "bugs" when the
explanation of their problem is in the manual) is of great importance.  
We need to encourage people to read it rather than being intimidated by
its size - necessary for a complicated tool - and ensure that the
information people want is easy for them to find in it.

-- 
Joseph S. Myers
jsm@polyomino.org.uk


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