This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: fixincl and fdopen and DJGPP
- To: Philippe De Muyter <phdm at macqel dot be>, Laurynas Biveinis <lauras at softhome dot net>, gcc-patches at gcc dot gnu dot org
- Subject: Re: fixincl and fdopen and DJGPP
- From: Bruce Korb <bkorb at sco dot COM>
- Date: Fri, 05 May 2000 15:03:29 -0700
- Organization: Santa Cruz Operations
- References: <200005052111.XAA24278@mail.macqel.be>
Philippe De Muyter wrote:
>
> Did you see my RFA regarding removing harmfull fdopen calls from fixincl.c
> some days ago ?
>
> Philippe
I check gcc-patches and gcc-bugs every few days for messages
bearing the string 'fixinc'. :-) I just got it from only two days ago.
See below.
Cheers,
Bruce
====================
Laurynas,
Which patch you you (and the rest of the DJGPP folks?) want?
Pick just one, please. Are there really no headers that cause
difficulties? - Thanks.
> fixincludes binary uses several features not supported by DJGPP
> (such as pipes), and GCC is a primary compiler there anyway, so
> IMHO it is reasonable to disable fixincludes there.
>
> 2000-05-05 Laurynas Biveinis <lauras@softhome.net>
>
> * fixinc/mkfixinc.sh: Don't fix DJGPP headers.
>
> --- cvs/gcc/gcc/fixinc/mkfixinc.sh Thu May 4 17:29:40 2000
> +++ gcc/gcc/fixinc/mkfixinc.sh Fri May 5 19:05:16 2000
> @@ -71,6 +71,7 @@
> *-*-linux-gnu* | \
> *-*-gnu* | \
> i[34567]86-moss-msdos* | i[34567]86-*-moss* | \
> + i[34567]86-pc-msdosdjgpp | \
> i[34567]86-*-osf1* | \
> i[34567]86-*-win32 | \
> i[34567]86-*-pe | i[34567]86-*-cygwin* | \
=========
> Currently bootstrap under DJGPP fails with
>
> 2000-05-05 Laurynas Biveinis <lauras@softhome.net>
>
> * fixincl/fixincl.c (initialize): handle SIGIOT only if it is defined.
>
> diff -u -r cvs/gcc/gcc/fixinc/fixincl.c gcc/gcc/fixinc/fixincl.c
> --- cvs/gcc/gcc/fixinc/fixincl.c Thu May 4 17:29:40 2000
> +++ gcc/gcc/fixinc/fixincl.c Fri May 5 18:37:20 2000
> @@ -368,7 +368,9 @@
> run_compiles ();
>
> signal (SIGQUIT, SIG_IGN);
> +#ifdef SIGIOT
> signal (SIGIOT, SIG_IGN);
> +#endif
> signal (SIGPIPE, SIG_IGN);
> signal (SIGALRM, SIG_IGN);
> signal (SIGTERM, SIG_IGN);
===========================================
> I finally managed to find (time to find) why fixincl was caught in an endless
> loop inside fwrite :(. It appears that the culprit are 2 useless fdopen calls
> (but harmfull on my platform). In the case below, the fdopen calls do not
> assign the new file descriptors to stdin and stout, but actually create new
> unused FILE *streams using the file descriptors 0 and 1. On sysV68, the
> implementation of stdio make bad things when two FILE * use the same file
> descriptor if it is 0 or 1.
>
> OK to commit ?
>
> Philippe De Muyter <phdm@macqel.be>
>
> * fixinc/fixincl.c (internal_fix): Remove the useless and harmfull
> fdopen calls.
>
> Index: fixincl.c
> ===================================================================
> RCS file: /cvs/gcc/egcs/gcc/fixinc/fixincl.c,v
> retrieving revision 1.29
> diff -u -p -r1.29 fixincl.c
> @@ -991,8 +989,6 @@ internal_fix (read_fd, p_fixd)
> */
> fcntl (fd[1], F_DUPFD, STDOUT_FILENO);
> fcntl (read_fd, F_DUPFD, STDIN_FILENO);
> - fdopen (STDIN_FILENO, "r");
> - fdopen (STDOUT_FILENO, "w");
>
> apply_fix (p_fixd->patch_args[0], pz_curr_file);
> exit (0);
Well, it may be true on your platform, but the docs I have seem to indicate
that you cannot rely on "stdin" and "stdout" pointing to the right things.
Otherwise, you would be able to use a macro to convert fd's to fp's just
as you currently *can* use macros to convert the other way. Therefore,
I believe the "correct" fix is to do a configure test and if-def away
these calls where they cause problems.