Hi,
Sterpu Mihai wrote:
> It seems the underlying implementation of mskstemp is different between
> glibc and gnulib.
> Specifically, in tempname.c function try_tempname_len.
> The local variable v of type random_value is initialized to 0 in gnulib:
>
> /* A random variable. */
> random_valu
Eric Blake wrote:
> > + dies from a fatal signal such as SIGQUIT, SIGKILL, or SIGABRT, SIGSEGV,
> > + SIGBUS, SIGILL, SIGFPE, */
>
> The grammar is a bit off, though. Should the "or" be moved to the end,
SIGQUIT, SIGKILL are signals forceful kill signals from outside the program,
whereas SI
On 04/27/2011 04:37 PM, Bruno Haible wrote:
> Eric Blake wrote:
>>> +# On some hosts, mkstemp creates files with mode 0666, which is a security
>>> +# problem.
>>
>> Also, it was valid in POSIX 2001, but violates POSIX 2008.
>
> What about mkstemps? Does it have the same problem as mkstemp?
In al
Eric Blake wrote:
> > +# On some hosts, mkstemp creates files with mode 0666, which is a security
> > +# problem.
>
> Also, it was valid in POSIX 2001, but violates POSIX 2008.
What about mkstemps? Does it have the same problem as mkstemp?
The answer is fortunately "no". The platforms x symbols
On 04/27/2011 03:29 PM, Bruno Haible wrote:
> Just "less likely"?! The code in module 'clean-temp' goes through all kinds of
> hoops with signal handlers and 'volatile' variables to make _sure_ that the
> temporary files are cleaned up. This has also been tested as part of the
> 'msgfmt' program.
>
Eric Blake wrote:
> I also think doc/posix-functions/mkstemp.texi could
> use a similar comment. I added that, and pushed the modified result.
Thanks, but...
"The gnulib module clean-temp can create temporary files that are less
likely to be left behind on signals such as SIGINT."
Just "le
On 27 April 2011 15:17, Eric Blake wrote:
>
> Can you convince your mailer to send patches inline, or at least with
> text/plain MIME type?
I think my only options are to rename the patch file (which will
change the mailer's diagnosed MIME type) or to manually paste the
patch into the body of the
On 04/27/2011 07:52 AM, Reuben Thomas wrote:
> On 27 April 2011 14:00, Eric Blake wrote:
>> On 04/27/2011 04:05 AM, Reuben Thomas wrote:
>>> On 27 April 2011 03:24, Bruno Haible wrote:
> Does setting a 0600 umask (as glibc does) sound like a good thing to
> add to the mkstemp-safer functi
On 04/27/2011 07:32 AM, Reuben Thomas wrote:
> On 27 April 2011 14:00, Eric Blake wrote:
>> On 04/27/2011 04:05 AM, Reuben Thomas wrote:
>>
>>> However, this suggests that the gnulib documentation for mkstemp
>>> should direct the programmer to clean-temp, something like:
>>>
>>> "If you are creat
On 27 April 2011 14:00, Eric Blake wrote:
> On 04/27/2011 04:05 AM, Reuben Thomas wrote:
>> On 27 April 2011 03:24, Bruno Haible wrote:
Does setting a 0600 umask (as glibc does) sound like a good thing to
add to the mkstemp-safer functions?
>
> Setting umask() is bad for other reasons -
On 27 April 2011 14:00, Eric Blake wrote:
> On 04/27/2011 04:05 AM, Reuben Thomas wrote:
>
>> However, this suggests that the gnulib documentation for mkstemp
>> should direct the programmer to clean-temp, something like:
>>
>> "If you are creating temporary files which will later be removed, cons
On 04/27/2011 04:05 AM, Reuben Thomas wrote:
> On 27 April 2011 03:24, Bruno Haible wrote:
>>> Does setting a 0600 umask (as glibc does) sound like a good thing to
>>> add to the mkstemp-safer functions?
Setting umask() is bad for other reasons - it is global state, and
should not be done in mult
On 27 April 2011 03:24, Bruno Haible wrote:
>> Does setting a 0600 umask (as glibc does) sound like a good thing to
>> add to the mkstemp-safer functions?
>
> The application can call chmod() on its own. Why push this
> into mkstemp-safer?
I'm not suggesting chmod (that would surely create a race
Reuben Thomas wrote:
> From mkstemp(3):
>
>More generally, the POSIX specification of mkstemp() does not
> say anything about file modes,
>so the application should make sure its file mode creation mask
> (see umask(2)) is set
>appropriately before calling mkstemp() (and mk
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 8/7/2008 3:28 AM:
> | I've just relicensed mkstemp to LGPLv2+,
> | and would like to do the same to its dependent module, tempname.
> | This is really just a formality, since the code is from glibc,
> |
> | Ok with you, Eric?
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 8/7/2008 3:28 AM:
| I've just relicensed mkstemp to LGPLv2+,
| and would like to do the same to its dependent module, tempname.
| This is really just a formality, since the code is from glibc,
|
| Ok with you, Eric?
Yes,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruce Korb on 3/20/2007 10:00 AM:
>> The reason is that mkstemp is declared in , not , on
>> this platform. But for POSIX compatibility, only gnulib's should
>> be sufficient to declare the function. I'm applying this:
>
> Just a questio
Bruno Haible wrote:
> Hello,
>
> On MacOS X 10.3, one gets this warning:
>
> mkstemp-safer.c:34: warning: implicit declaration of function `mkstemp'
>
> The reason is that mkstemp is declared in , not , on
> this platform. But for POSIX compatibility, only gnulib's should
> be sufficient to dec
Jim Meyering <[EMAIL PROTECTED]> wrote:
> The problem is that on systems for which m4/mkstemp.c
> would normally make an application use the replacement
> function, an application calling mkstemp_safer would end up
> using the buggy version, because mkstemp-safer.c didn't
> include (for the mkstem
19 matches
Mail list logo
