Eric Blake wrote:
> Is it okay to apply this patch, to reduce make output clutter?
Yes, please apply.
Bruno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 10/7/2006 11:46 AM:
> Eric Blake wrote:
>> Thanks for putting up with my critiques; I think the clean-temp module is
>> better for it
>
> Thanks for the critiques! I think the clean-temp module has improved more
> in the t
Eric Blake wrote:
> Thanks for putting up with my critiques; I think the clean-temp module is
> better for it
Thanks for the critiques! I think the clean-temp module has improved more
in the three months since you and Paul got to look at it, than during
the previous three years where it was "hidde
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 10/7/2006 9:06 AM:
>> 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
Eric Blake wrote:
> Grammar: s/one can/can one/
Thanks, applied.
> > --- gnulib-20060928-modified/lib/clean-temp.c 2006-10-06
> > 03:37:05.0 +0200
> > ***
> > *** 41,46
> > --- 41,50
> >
> > #define _(str) gettext (str)
> >
> > + #ifndef uintptr_t
> > + # de
Eric Blake wrote:
> M4 needs to know if
> anything was written to stderr, so that it can exit with non-zero status
> if the cleanup of temp files failed for any reason.
You really want m4 to exit with non-zero status just because it couldn't
clean up in /tmp? Oh well. It's implementable.
2006-10
Eric Blake wrote:
> May I apply the patch below to gnulib?
Yes, fine with me. Please apply.
> Also, I'm suspicious of your use of xallocsa with PATH_MAX, on platforms
> like Hurd where PATH_MAX is intentionally undefined because there is no
> limit
Well seen. I'm adding this.
*** clean-temp.c
Eric Blake <[EMAIL PROTECTED]> writes:
> May I apply the patch below to gnulib?
That's fine with me, for the close-stream/fcntl-safer/stdio-safer
side. I wish there were a simpler way but I don't see it offhand.
(Bruno of course needs to look at the clean-temp side.)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 10/6/2006 7:43 AM:
>
> You are free to add a close_stream_temp function to the create-temp module
> if you protect it with #ifdef so that it doesn't introduce a module
> dependency.
May I apply the patch below to gnulib?
Eric Blake wrote:
> Suppose the user is perverse
> enough (usually, only when trying to hammer out corner cases just like
> this ;) to run with a umask of 702 (ie. they want group but not user
> privileges). As written, the current code creates an unusable directory.
> Either we must document tha
PS: I also changed the javacomp module to make use of the new functions.
2006-10-06 Bruno Haible <[EMAIL PROTECTED]>
* javacomp.c (write_temp_file): Use fopen_temp, fwriteerror_temp
instead of fopen, fwriteerror.
*** javacomp.c 14 Sep 2006 14:18:36 - 1.7
--- javacomp.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 10/6/2006 6:14 AM:
Comments just from reading the source:
>
>> fwriterror is still controversial for the reasons Paul mentioned
>
> But I need it in GNU gettext.
I think I misunderstood you in my previous mail. Implem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 10/6/2006 6:14 AM:
> Eric Blake wrote:
>> Hmm. The gnulib mkdtemp module does not take umask into account. Neither
>> does the mkdtemp variant of lib/tempname.c. Shouldn't these modules be
>> guaranteeing that the direct
Eric Blake wrote:
> Hmm. The gnulib mkdtemp module does not take umask into account. Neither
> does the mkdtemp variant of lib/tempname.c. Shouldn't these modules be
> guaranteeing that the directory created has full user permissions, in
> spite of the current umask? Or is it the caller's respo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 10/5/2006 6:30 AM:
>
> It's the latter: You can choose arbitrary file names in the temp_dir. For
> example, you could safely unzip a file in the temp_dir (assuming none of
> the file names contain a ".." component :-)).
H
Eric Blake wrote:
> It looks like using mkstemp
> (/templateXX) is not safe; I must instead invent a
> name,
> call register_temp_file with that name, then create the file, then
> unregister_temp_file if the creation failed. When creating the name, do I
> have
> to worry about making the
16 matches
Mail list logo
