[gnu.gcc] gcc 1.35 failed on build flex

moraes@csri.toronto.edu (Mark Moraes) (05/16/89)

In article <90@zip.eecs.umich.edu> yhe@zip.eecs.umich.edu.UUCP (Youda He) writes:
>When replace cc to gcc in build flex, the result flex dump core.on test.
>Segmentation fault. System is sun4 os4.

Without a stack backtrace, all I can do is guess that you're having
the mktemp() problem.

The version of flex I ftp'ed off rtsg.ee.lbl.gov compiled and ran fine
and worked with cc - with gcc, it died with a core dump because it
invoked mktemp() with a constant string, which gcc puts in read-only
text space.  My fix follows - an alternative is to use
-fwritable-strings.

*** /tmp/,RCSt1a20602	Mon Mar  6 20:52:42 1989
--- main.c	Sat Mar  4 14:27:09 1989
***************
*** 54,60
  int tmpuses, totnst, peakpairs, numuniq, numdup, hshsave;
  FILE *temp_action_file;
  int end_of_buffer_state;
! char *action_file_name = "/tmp/flexXXXXXX";
  
  
  /* flex - main program

--- 54,61 -----
  int tmpuses, totnst, peakpairs, numuniq, numdup, hshsave;
  FILE *temp_action_file;
  int end_of_buffer_state;
! #define TEMPFILETEMPLATE "/tmp/flexXXXXXX"
! char *action_file_name;
  
  
  /* flex - main program
***************
*** 68,73
  char **argv;
  
      {
      flexinit( argc, argv );
  
      readin();

--- 69,84 -----
  char **argv;
  
      {
+     char *malloc();
+ 
+     if ((action_file_name = malloc(sizeof(TEMPFILETEMPLATE))) == NULL)
+ 	{
+ 	fprintf(stderr, "Malloc failed\n");
+ 	exit(1);
+ 	}
+ 	
+     (void) strcpy(action_file_name, TEMPFILETEMPLATE);
+     
      flexinit( argc, argv );
  
      readin();

bothner@decwrl.dec.com (Per Bothner) (05/17/89)

In article <89May16.031927edt.741@church.csri.toronto.edu> moraes@csri.toronto.edu (Mark Moraes) writes:
A fix is provided to get solve the crash when mktemp() is
called with a read-only string.

A better solution to problems of this sort is the following:
Change:
char *action_file_name = "/tmp/flexXXXXXX";
to:
char action_file_name[] = "/tmp/flexXXXXXX";
This is simpler and faster than malloc'ing a copy.
-- 
	--Per Bothner
Western Software Lab, Digital Equipment, 100 Hamilton Ave, Palo Alto CA 94301
bothner@wsl.dec.com ...!decwrl!bothner