Solaris mktemp()

106 views
Skip to first unread message

Rodrick Brown

unread,
Apr 30, 2005, 10:49:32 AM4/30/05
to
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;


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

unread,
Apr 30, 2005, 11:02:54 AM4/30/05
to
Rodrick Brown <rodric...@gmail.com> wrote:
> 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

unread,
Apr 30, 2005, 12:45:50 PM4/30/05
to
On Sat, 30 Apr 2005, Rodrick Brown wrote:

> 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

unread,
Apr 30, 2005, 2:32:13 PM4/30/05
to
Rich Teer <rich...@rite-group.com> wrote:

> 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

unread,
Apr 30, 2005, 3:15:03 PM4/30/05
to
"Rodrick Brown" <rodric...@gmail.com> writes:

>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

unread,
Apr 30, 2005, 3:34:06 PM4/30/05
to
In article <4273d937$0$151$e4fe...@news.xs4all.nl>,

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

unread,
Apr 30, 2005, 3:44:48 PM4/30/05
to
Jonathan Adams <jwa...@gmail.com> writes:

> return (fifod);

The original function also worked only once.

Rodrick Brown

unread,
Apr 30, 2005, 7:01:39 PM4/30/05
to

"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

unread,
Apr 30, 2005, 7:07:07 PM4/30/05
to
Rodrick Brown <rodric...@gmail.com> wrote:
> 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

unread,
May 1, 2005, 3:30:00 AM5/1/05
to
"Rodrick Brown" <rodric...@gmail.com> writes:

>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

unread,
May 2, 2005, 11:37:32 AM5/2/05
to
Rodrick Brown wrote:>
> 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

Reply all
Reply to author
Forward
0 new messages