Re: [bug-gnulib] clean-temp usage question

[Bruno Haible]

Eric Blake wrote:
> Grammar: s/one can/can one/

Thanks, applied.

> > --- gnulib-20060928-modified/lib/clean-temp.c       2006-10-06 
> > 03:37:05.000000000 +0200
> > ***************
> > *** 41,46 ****
> > --- 41,50 ----
> >
> >   #define _(str) gettext (str)
> >
> > + #ifndef uintptr_t
> > + # define uintptr_t unsigned long
> > + #endif
> > +
> 
> Can't we just get this by including one of the gnulib headers that
> guarantees the correct types?  I'm a bit worried that there might be a
> platform with uintptr_t typedef'd to a different size integer, at which
> point this #define is broken.

This would be harmless. The uintptr_t here is only used to cast between
'int' and 'void *'. If it is the wrong size, the worst thing that can
happen is that gcc emits some warnings.

> > +   saved_errno = errno;
> > +   if (fp != NULL)
> > +     {
> > +       /* It is sufficient to register fileno (fp) instead of the entire 
> > fp,
> > +    because at cleanup time there is no need to do an fflush (fp); a
> > +    close (fileno (fp)) will be enough.  */
> 
> At fatal signal time, yes, calling fflush is unnecessary - the program is
> going to die from the signal anyways, so losing unflushed data does not
> hurt my feelings.  But it does mean that I must manually fflush/fclose all
> returned FILE*s before calling cleanup_temp_subdir (although it is good
> practice to do that anyways).

Yes, you will do it anyway. If you make up a temp file and you would
consider losing unflushed data a bug, there must be some program going
to read the data after this point. Which is impossible if you already
call cleanup_temp_subdir at this point.

> > +       /* No race condition here: we assume a single-threaded program, 
> > hence
> > +    fd cannot be re-opened here.  */
> 
> State that assumption in the comments for create_temp_dir.

gnulib modules are not MT-safe by default. We can at some point start
adding comments "this API is MT-safe" in each module, when needed.

> Is it worth documenting that given a FILE* from fopen_temp, I can do:
> fd=fileno(fp); close_stream(fp); close_temp(fd);
> rather than:
> fclose_temp(fp);

In which situations would it be useful to know this? Few programs hack
around with fileno and freopen.

> Once fp is closed, I can't call fclose_temp because the storage underlying
> fp is no longer valid, but if you provide a guarantee that I only have to
> unregister the fd, then I can choose between close_stream (which M4 is
> already using) or converting over to fwriteerror for disposing of
> temporary FILE* objects.

Use close_stream_temp. Simple enough.

Bruno