Unix Programming - POSIX mkstemp and gcc

Author

POSIX mkstemp and gcc

claudibus

2004-01-23, 4:57 pm

Hello,
I am revising some code to make it POSIX compliant, but after some
work removing system specific stuff, I have found something strange
about mkstemp:

$ man 3 mkstemp
[cut] CONFORMING TO:
BSD 4.3, POSIX 1003.1-2001 [cut]

$ gcc -ansi -pedantic -D_POSIX_SOURCE [cut]

warning: implicit declaration of function `mkstemp'

That is what i get even though both <stdlib.h> and <unistd.h> are
included and mkstemp appears to be a POSIX 1003.1 function.

I then tried #define _POSIX_C_SOURCE with reasonable and unreasonable
values without any outcome

How can I get rid of this warning?

Linux 2.4.20,
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Configured with: ../configure --prefix=/usr
Thread model: posix
gcc version 3.3.2

DINH =?iso-8859-15?Q?Vi=EAt_Ho=E0?=

2004-01-23, 4:57 pm

sick_soul@yahoo.it wrote :

quote:

> I am revising some code to make it POSIX compliant, but after some
> work removing system specific stuff, I have found something strange
> about mkstemp:
>
> $ man 3 mkstemp
> [cut] CONFORMING TO:
> BSD 4.3, POSIX 1003.1-2001 [cut]
>
> $ gcc -ansi -pedantic -D_POSIX_SOURCE [cut]

could you show some minimal version of your code that shows the warning ?
are you sure you need -D_POSIX_SOURCE ?
Do you know all the effect ?
maybe one of these effet is disabling some functions that were previously
not is the POSIX standards ?

--
DINH V. Hoa,

"monde de merde" -- Erwan David

Michael Fuhr

2004-01-23, 4:57 pm

sick_soul@yahoo.it (claudibus) writes:

quote:

> I am revising some code to make it POSIX compliant, but after some
> work removing system specific stuff, I have found something strange
> about mkstemp:
>
> $ man 3 mkstemp
> [cut] CONFORMING TO:
> BSD 4.3, POSIX 1003.1-2001 [cut]
>
> $ gcc -ansi -pedantic -D_POSIX_SOURCE [cut]

According to the standard, _POSIX_SOURCE has been superseded by
_POSIX_C_SOURCE.

quote:

> warning: implicit declaration of function `mkstemp'
>
> That is what i get even though both <stdlib.h> and <unistd.h> are
> included and mkstemp appears to be a POSIX 1003.1 function.
>
> I then tried #define _POSIX_C_SOURCE with reasonable and unreasonable
> values without any outcome

It doesn't matter in this case, but it's usually a good idea to
mention what "reasonable and unreasonable values" you tried so
others can see if they look right.

quote:

> How can I get rid of this warning?
>
> Linux 2.4.20,

The specification for mkstemp() at www.opengroup.org indicates that
it's an XSI extension. On the Linux system I checked, the declaration
for mkstemp() in <stdlib.h> was inside the following preprocessor
conditional:

#if defined __USE_MISC || defined __USE_XOPEN_EXTENDED

If you define _XOPEN_SOURCE to a value >= 500 (I usually use 600)
then __USE_XOPEN_EXTENDED should be automatically defined by
<features.h>; this should get you the declaration for mkstemp().

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

claudibus

2004-01-23, 4:57 pm

Thank you for your clarifications, I am very new to these standard
issues.
What I meant by "reasonable and unreasonable" values was that I first
tried with

#define _POSIX_C_SOURCE 199506L

and then started adding up to the number hoping to find a new value
that is
checked with >= like 199506L is. It was silly.

quote:

> If you define _XOPEN_SOURCE to a value >= 500 (I usually use 600)
> then __USE_XOPEN_EXTENDED should be automatically defined by
> <features.h>; this should get you the declaration for mkstemp().

this is precious information which solves my problem at hand, and I
thank you.
Could I ask you where to find some additional information? Things like
which unix flavours and systems support, for example, POSIX.1 but not
the XSI extensions, or a list of common practices/checklist to keep in
mind when convering a UNIX-implementation specific source to a
specific POSIX standard source.

Thanks for the help

Claudio

Jens.Toerring@physik.fu-berlin.de

2004-01-23, 4:57 pm

claudibus <sick_soul@yahoo.it> wrote:

quote:

> Hello,
> I am revising some code to make it POSIX compliant, but after some
> work removing system specific stuff, I have found something strange
> about mkstemp:

quote:

> $ man 3 mkstemp
> [cut] CONFORMING TO:
> BSD 4.3, POSIX 1003.1-2001 [cut]

quote:

> $ gcc -ansi -pedantic -D_POSIX_SOURCE [cut]

quote:

> warning: implicit declaration of function `mkstemp'

Have a look at the info pages for gcc

`-ansi'
Support all ANSI standard C programs.

....

The macro `__STRICT_ANSI__' is predefined when the `-ansi' option
is used. Some header files may notice this macro and refrain from
declaring certain functions or defining certain macros that the
ANSI standard doesn't call for; this is to avoid interfering with
any programs that might use these names for other things.

So, when you use extensions to the set of functions defined in the
C standard (like mkstemp()), the '-ansi' flag usually doesn't make
too much sense because it's not a strict ANSI C program anymore.

Regards, Jens
--
_ _____ _____
| ||_ _||_ _| Jens.Toerring@physik.fu-berlin.de
_ | | | | | |
| |_| | | | | | http://www.physik.fu-berlin.de/~toerring
\___/ens|_|homs|_|oerring

claudibus

2004-01-23, 4:58 pm

From the small experience I've had with standard-oriented compilation
I'm told otherwise, but I might be wrong.

quote:

> Have a look at the info pages for gcc
>
> `-ansi'
> Support all ANSI standard C programs.
>[cut]

quote:

> So, when you use extensions to the set of functions defined in the
> C standard (like mkstemp()), the '-ansi' flag usually doesn't make
> too much sense because it's not a strict ANSI C program anymore.

It does make sense IMO. My thought is, the -ansi flag makes an initial
restriction to the smallest subset of API compatible with the C
Standard (specifying I want the C89/C90 Standard), and eliminates
other non C things such as // comments, asm, typeof, and puts
trigraphs and other things in. Coupled with the -Wall -pedantic gives
a small hope that the code is compiled through the intended Standard C
way (no guarantee though).

At this point I can add up some extensions using additional macroes to
add up specific extensions in my case:

_POSIX_SOURCE to include functionalities defined in POSIX.1
or better (as someone just told me

)
_POSIX_C_SOURCE nnnn to include .1, .2. .1b,
...
_XOPEN_SOURCE n (> 500) to include the posix extensions I was looking
for

So I think, as you say, it is not an ANSI C program anymore, but yes,
it does have sense. For example I could say

gcc -Wall -pedantic -std=c99 -D_POSIX_SOURCE /* some units here */
to specify I want the c99 standard instead of -ansi (which is c89-90),
don't you think?

Claudio

Jens.Toerring@physik.fu-berlin.de

2004-01-23, 4:58 pm

claudibus <sick_soul@yahoo.it> wrote:

quote:

[QUOTE][color=darkred]
> It does make sense IMO. My thought is, the -ansi flag makes an initial
> restriction to the smallest subset of API compatible with the C
> Standard (specifying I want the C89/C90 Standard), and eliminates
> other non C things such as // comments, asm, typeof, and puts
> trigraphs and other things in. Coupled with the -Wall -pedantic gives
> a small hope that the code is compiled through the intended Standard C
> way (no guarantee though).

quote:

> At this point I can add up some extensions using additional macroes to
> add up specific extensions in my case:

quote:

> _POSIX_SOURCE to include functionalities defined in POSIX.1
> or better (as someone just told me )
> _POSIX_C_SOURCE nnnn to include .1, .2. .1b,
> ...
> _XOPEN_SOURCE n (> 500) to include the posix extensions I was looking
> for

quote:

> So I think, as you say, it is not an ANSI C program anymore, but yes,
> it does have sense. For example I could say

I never wanted to imply that it's without merits to try to compile
a program with '-ansi' to pinpoint possible problems etc, but when
you are asking specifically

"How can I get rid of this warning?"

then I would guess that the only way is to either not use non-ASCII
functions or to drop the '-ansi' flag. Otherwise, at least as far
as I understand it, it would be like asking for a perfect sphere,
but with corners ;-)
Regards, Jens
--
_ _____ _____
| ||_ _||_ _| Jens.Toerring@physik.fu-berlin.de
_ | | | | | |
| |_| | | | | | http://www.physik.fu-berlin.de/~toerring
\___/ens|_|homs|_|oerring

claudibus

2004-01-23, 4:59 pm

> I never wanted to imply that it's without merits to try to compile

quote:

> a program with '-ansi' to pinpoint possible problems etc, but when
> you are asking specifically
>
> "How can I get rid of this warning?"
>
> then I would guess that the only way is to either not use non-ASCII
> functions or to drop the '-ansi' flag.

There's another way (surely you mean non-ANSI functions) to get rid of
the warning, which is finding which standard contains mkstemp() and
telling the compiler to adhere to that standard using the feature test
macros:

http://www.gnu.org/manual/glibc-2.2...de/libc_13.html

there is not only the ansi standard around: I use the -ansi -pedantic
flags
to select the ANSI standard (to polish the language and get the
standard library without strange non-standard behaviours) and then
select that extension which I need/prefer.

Since the ANSI C functions to create temporary files of known
filenames are insecure in a multi-process environment, I had to
(regretfully) decide to adhere to an extension (_XOPEN_SOURCE) to gain
a better function (mkstemp).

quote:

> Otherwise, at least as far
> as I understand it, it would be like asking for a perfect sphere,
> but with corners ;-)

Yes, I guess sometimes one needs that

Claudio