yhe@zippy.eecs.umich.edu (Youda He) (05/15/89)
When replace cc to gcc in build flex, the result flex dump core.on test. Segmentation fault. System is sun4 os4.
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