egcs bug? (fwd)

Paul Ezust ezust@zeus.cas.suffolk.edu
Tue Dec 22 01:18:00 GMT 1998


Not to beat a dead horse, but:

c++> cat strange.cc
#include <iostream.h>
int main()
{
  char * const b = "abcdef";
  b[3] = '3'; 
  cout << b << endl;
}

c++> g++ -ansi -pedantic -Wall strange.cc
c++> a.out
Segmentation fault
c++>
[ gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release) ]


I wonder why the egcs compiler does not at least give a warning if a
programmer attempts to declare a char* that points to a const char *? 

I can see why the behavior of a program that tries to modify a string
literal would be "undefined", but it seems to me that we should need to do
a type-cast in order to make that modification possible without a
compiler warning, i.e.,

	char *str = const_cast<char *>("Hello world");

Then if we get a segmentation fault, it's our OWN darned fault,
segmentation or otherwise.



On 21 Dec 1998, Alexandre Oliva wrote:

> On Dec 20, 1998, Paul Ezust <ezust@zeus.cas.suffolk.edu> wrote:
> 
> > I was confused by the three different compiler behaviors that
> > I described in my first message:
> 
> >    gcc version egcs-2.90.27 980315 (egcs-1.0.2 release)
> >    gives an "Internal compiler error".
> 
> This was a bug that was fixed in release 1.1 (or was it 1.0.3?)
> 
> >    gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)
> >    compiles it but produces a run-time error (segmentation fault)
> 
> >    Centerline C++ compiler compiles and runs it with no problem.
> >    (Centerline sells a unix IDE called ObjectCenter.)
> 
> > One colleague seems to think that compiling it so that it produces
> > a run-time error is the correct way to handle that error.
> > That makes me a bit queasy.
> 
> A program that tries to modify a literal string is completely
> unpredictable, because the Standard says it produces undefined
> behavior.  It could wipe out your hard disk, start `hack' or even
> reboot the universe :-)
> 
> Segmentation fault is fine, and allowing the modification is fine
> too.  Producing any run-time error other than segmentation fault would 
> be probably too costly (checking every access) or too unportable
> (catching SIGSEGV).
> 
> -- 
> Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
> oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
> Universidade Estadual de Campinas, SP, Brasil
> 
> 

---------------------------------------------------------------------
Paul Ezust					Phone: (617) 573-8601
Department of Math & CS				Fax:   (617) 573-8591
Suffolk University    ***    Beacon Hill  ***   Boston, MA  02114-4280






More information about the Gcc-bugs mailing list