On Sun, Aug 28, 2011 at 7:30 AM, Bruno Haible <br...@clisp.org> wrote: > Hi Michael, > >> It appears the problem comes from the fact that stdio.h is pulled in >> indirectly from >> config.h, hence it is not surrounded by the __need_FILE macro that should >> prevent >> the problem from occuring. The inclusion pattern is: >> >> config.h >> stdint.h (because of octave config.h content) >> wchar.h (because of stdint.h implementation I'm using, see [1]) >> stdio.h (because of wchar.h implementation in gnulib) > > Thanks for this analysis. While including system header files from within > config.h can be problematic > (cf. http://www.gnu.org/software/gnulib/manual/html_node/Source-changes.html), > gnulib should not cause infinite recursions because of it. > > Can you please try this patch? > > --- a/lib/fopen.c > +++ b/lib/fopen.c > @@ -16,7 +16,12 @@ > > /* Written by Bruno Haible <br...@clisp.org>, 2007. */ > > +/* If the user's config.h happens to include <stdio.h>, let it include only > + the system's <stdio.h> here, so that orig_fopen doesn't recurse to > + rpl_fopen. */ > +#define _GL_ALREADY_INCLUDING_STDIO_H > #include <config.h> > +#undef _GL_ALREADY_INCLUDING_STDIO_H > > /* Get the original definition of fopen. It might be defined as a macro. */ > #define __need_FILE
Yes, it fixes the problem, thanks. Note that a similar problem may occur in open.c, though it didn't for me (I checked the preprocessed source file and it didn't show the issue). Michael.
