Solaris mktemp()
Rodrick Brown
application just core dumps i've narrowed it down to the way mktemp()
behaves on Solaris compares to MacOSX any reason why this snipnett of code
would work on Solaris but not other OS's
Here is a a sample code of what the application is doing
char *fifod;
if (( fifod = mktemp("/tmp/A9XXXXXX")) == NULL)
{
perror("fatal: mktemp()");
return NULL;
}
return fifod;
If there is a better way to do above i'm open to any working solution
thanks.
--
Rodrick R. Brown
Unix Systems Admin
http://www.rodrickbrown.com
rodrick.brown[@]gmail.com
Thomas Dickey
> I'm porting an application from Solaris to MacOSX and for some reason the
> application just core dumps i've narrowed it down to the way mktemp()
> behaves on Solaris compares to MacOSX any reason why this snipnett of code
> would work on Solaris but not other OS's
The parameter is a readonly string; mktemp() requires a writable buffer.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Rich Teer
> I'm porting an application from Solaris to MacOSX and for some reason the
> application just core dumps i've narrowed it down to the way mktemp()
> behaves on Solaris compares to MacOSX any reason why this snipnett of code
> would work on Solaris but not other OS's
>
> Here is a a sample code of what the application is doing
>
> char *fifod;
> if (( fifod = mktemp("/tmp/A9XXXXXX")) == NULL)
> {
> perror("fatal: mktemp()");
> return NULL;
> }
> return fifod;
mktemp replaces the contents of the string you pass it with the new file
name, but you're passing it a constant that can't be overwritten.
> If there is a better way to do above i'm open to any working solution
> thanks.
There's a potential race hazard when using mktemp and open et al
to create the temporary file, so using mkstemp is preferred if
possible. I cover this in my book, Solaris Systems Programming.
HTH,
--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
Thomas Dickey
> There's a potential race hazard when using mktemp and open et al
> to create the temporary file, so using mkstemp is preferred if
> possible. I cover this in my book, Solaris Systems Programming.
is that so?
The section on mkstemp, etc., is derived from the Solaris manpage
(that contains more information than your book ;-).
I don't see race conditions discussed in that section (pp 108-110).
Race conditions (as found in the index) apply to different features
than temporary files.
Perhaps you could cite a (valid) reference.
Casper H.S. Dik
>I'm porting an application from Solaris to MacOSX and for some reason the
>application just core dumps i've narrowed it down to the way mktemp()
>behaves on Solaris compares to MacOSX any reason why this snipnett of code
>would work on Solaris but not other OS's
Are you using gcc?
The way you're calling mktemp is illegal because the string
may not be writable.
> char *fifod;
> if (( fifod = mktemp("/tmp/A9XXXXXX")) == NULL)
Use:
char tmpl[] = "/tmp/A9XXXXXX";
if ((fifod = mktemp(tmpl)) == NULL)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Jonathan Adams
Casper H.S. Dik <Caspe...@Sun.COM> wrote:
> > char *fifod;
> > if (( fifod = mktemp("/tmp/A9XXXXXX")) == NULL)
>
> Use:
>
> char tmpl[] = "/tmp/A9XXXXXX";
>
> if ((fifod = mktemp(tmpl)) == NULL)
Except that the original code then does:
return (fifod);
which will now return an automatic array, which will probably break.
Perhaps making it static will work; the old code could never reliably
be called more than once.
This can't be fixed in general without changing the interface (i.e.
returning a newly malloc()ed buffer)
Cheers,
- jonathan
Casper H.S. Dik
> return (fifod);
The original function also worked only once.
Rodrick Brown
"Casper H.S. Dik" <Caspe...@Sun.COM> wrote in message
news:4273d937$0$151$e4fe...@news.xs4all.nl...
But for some reason this works fine in Solaris, are all pages writable by
default ?
The compiler i'm using on Solaris is Sun C 5.7 2005/01/07 on MacOSX Tiger
its gcc 3.4
--
Rodrick R. Brown
Thomas Dickey
> But for some reason this works fine in Solaris, are all pages writable by
> default ?
> The compiler i'm using on Solaris is Sun C 5.7 2005/01/07 on MacOSX Tiger
> its gcc 3.4
Whether strings are writable is a compiler option.
Casper H.S. Dik
>But for some reason this works fine in Solaris, are all pages writable by
>default ?
It works for some compilers and not others and not will all
sets of options.
>The compiler i'm using on Solaris is Sun C 5.7 2005/01/07 on MacOSX Tiger
>its gcc 3.4
gcc defaults to non-writable strings; Sun's C compiler defaults to
writable strings.
Thomas Maier-Komor
> But for some reason this works fine in Solaris, are all pages writable by
> default ?
> The compiler i'm using on Solaris is Sun C 5.7 2005/01/07 on MacOSX Tiger
> its gcc 3.4
>
> --
> Rodrick R. Brown
>
>
Because you are triggering UB (undefined behavior).
See section 6.4.5 paragraph 6 of ISO/IEC9899:1999:
"If the program attempts to modify such an array, the behavior is
undefined."
I.e. the result could also be a melted CPU (just kidding...)
Tom