nce is that on Linux the following small application
> produces different temporary files at each invocation:
>
> #include
> #include
> #include
> #include
>
> char tmpl[100];
>
> int main()
> {
> strncpy(tmpl, "stXX", 8);
> // crea
#include
#include
#include
char tmpl[100];
int main()
{
strncpy(tmpl, "stXX", 8);
// create temp file
int fd = mkstemp(tmpl);
printf("%s\n", tmpl);
//close and remove file immediately after
close(fd);
remove(tmpl);
return 0;
}
while on Windows, when b
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 i
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&qu
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.
>
> 2011-04-27 Reuben Thomas
> and Eric Blake
>
> + mkstemp: replace if system version uses wrong permissions
> + * m4/mkstemp.m4 (gl_FUNC_MKSTEMP): Add test for non-owner
> + read/write mode bits set in file created by mkstemp.
> + * doc/posix-f
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 04/27/2011 10:24 AM, Reuben Thomas wrote:
> On 27 April 2011 16:33, Eric Blake wrote:
>>
>> Here's the final version I'd like to push. It's modified a bit from
>> your version; are you okay with it still being in your name?
>
> Thanks very much for polishing and testing this patch; I don't mi
On 27 April 2011 16:33, Eric Blake wrote:
>
> Here's the final version I'd like to push. It's modified a bit from
> your version; are you okay with it still being in your name?
Thanks very much for polishing and testing this patch; I don't mind if
my name is still on it.
--
http://rrt.sc3d.org
From: Reuben Thomas
* m4/mkstemp.m4 (gl_FUNC_MKSTEMP): Add test for non-owner
read/write mode bits set in file created by mkstemp.
* doc/posix-functions/mkstemp.texi (mkstemp): Document the fix.
Signed-off-by: Eric Blake
---
Here's the final version I'd like to push. It's modi
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
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, so
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?
>
> S
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 temporar
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
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 (
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 c
>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 mkostemp()).
Does setting a 0
Similarly for the mkstemp function: I'm seeing this error:
../gllib/stdlib.h:600: error: `mkstemp' was not declared in this scope
> Here it becomes necessary to distinguish the two cases, like we do for many
> other functions.
Likewise here. This fixes it.
2010-04-
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,
&g
-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?
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?
>From eb8c6a45f2a176b5b070f56ce7d5c87c9235ba84 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAI
-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'
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
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 declare the function. I'
I intsalled this:
2006-09-20 Paul Eggert <[EMAIL PROTECTED]>
* modules/mkstemp (Files): Add mkstemp.h.
--- modules/mkstemp 20 Sep 2006 18:48:29 - 1.10
+++ modules/mkstemp 20 Sep 2006 22:32:08 -
@@ -2,6 +2,7 @@ Description:
mkstemp() function: create a p
I also installed this further change, which shouldn't hurt either.
That old HAVE_MKSTEMP code was bogus anyway, since it should have
been HAVE_DECL_MKSTEMP.
2006-09-20 Paul Eggert <[EMAIL PROTECTED]>
* mkstemp-safer.c: Include "mkstemp.h" instead of .
(mk
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
I found this bug by inspection.
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 mkstemp -> mks
31 matches
Mail list logo
