#define _XOPEN_SOURCE 600 - where to define?
Poster Matt
design consisting of 5 C files and headers.
In my single C file approach it was simple, I defined _XOPEN_SOURCE at the top
of the C file like this:
#ifndef _XOPEN_SOURCE
#define _XOPEN_SOURCE 600
#endif
Having split the project into multiple .c and .h files, I received a confusing
compiler warning (one of the modules uses nftw):
"warning: 'struct FTW' declared inside parameter list"
"warning: its scope is only this definition or declaration, which is probably
not what you want"
At first I thought this was a failure to #include <ftw.h> in the correct places
but it wasn't. Eventually after a lot of frustrating attempts to get rid of the
compiler warning I discovered that if I added this...
#ifndef _XOPEN_SOURCE
#define _XOPEN_SOURCE 600
#endif
...to the top of the C file which contains the (only) call to nftw() the warning
is no longer shown.
I suppose I am a bit confused about exactly where and when I should define
"#define _XOPEN_SOURCE 600"? [and do I need the #ifndef...#endif around the
#define?]
Can someone explain this to me please?
Thanks and regards, from a somewhat confused,
Matt
Jens Thoms Toerring
You should define _XOPEN_SOURCE before you include <ftw.h> since
what gets included from <ftw.h> already may depend on this macro
being set or not (e.g. nftw() or 'struct FTW' may not become de-
clared if it's not set). So the best place is probably in the
header file that includes <ftw.h>, before the line where you
include <ftw.h> (or in the C file if you include <ftw.h> there
and not in one of your header files).
The '#ifndef _XOPEN_SOURCE' is useful if there's a chance that
_XOPEN_SOURCE has already been defined somewhere else (e.g. in
some other header file). In that case trying to define it anew
would upset the compiler.
BTW, according to my (Linux) man page for nftw() you need to set
_XOPEN_SOURCE to 500 only.
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
David Schwartz
> I suppose I am a bit confused about exactly where and when I should define
> "#define _XOPEN_SOURCE 600"? [and do I need the #ifndef...#endif around the
> #define?]
You have a lot of choices, but the short version is that any C/C++
files that uses POSIX features should specify the version of the POSIX
standard that it was coded to.
You can add it to the compile command line with "-D_XOPEN_SOURCE=600".
You can put it in each C/C++ file before any files are included. You
can put it in your include files before any system headers are
included.
> Can someone explain this to me please?
You would be pretty angry if you had included 'ftw.h' to get the
prototype for 'ftw' and had your own function called 'nftw'. The
compiler has no way to know that you've seen the 2008 (or later) POSIX
specification unless you tell it.
DS
Ben Bacarisse
> Yesterday I split one large C file and its header into a more
> manageable modular design consisting of 5 C files and headers.
>
> In my single C file approach it was simple, I defined _XOPEN_SOURCE at
> the top of the C file like this:
>
> #ifndef _XOPEN_SOURCE
> #define _XOPEN_SOURCE 600
> #endif
<snip>
> I suppose I am a bit confused about exactly where and when I should
> define "#define _XOPEN_SOURCE 600"? [and do I need the
> #ifndef...#endif around the #define?]
I'd say you don't need the #ifndef. In fact I'd say it might even be
wrong to have it (unless you know why it was written like that in the
first place). There macros are state what features (usually from the
system headers) your code needs. If your code needs _XOPEN_SOURCE to
be 600, the honouring some other setting may not be correct.
If you just #define _XOPEN_SOURCE then you'll helpfully get an error
if some other part of the build sets it to something else.
Alternatively, you can silently force it to be 600 by using #undef
first.
This is just a rule of thumb. The lines you used might come from a
build system where only acceptable values for _XOPEN_SOURCE can be
chosen but where 600 should be used as a default. My point is that it
is probably wrong unless you know why it is written like that.
--
Ben.
Poster Matt
Okay. Many thanks Jens.
Poster Matt
> On Mar 7, 5:15 am, Poster Matt <postermatt@no_spam_for_me.org> wrote:
>
>> I suppose I am a bit confused about exactly where and when I should define
>> "#define _XOPEN_SOURCE 600"? [and do I need the #ifndef...#endif around the
>> #define?]
>
> You have a lot of choices, but the short version is that any C/C++
> files that uses POSIX features should specify the version of the POSIX
> standard that it was coded to.
>
> You can add it to the compile command line with "-D_XOPEN_SOURCE=600".
> You can put it in each C/C++ file before any files are included. You
> can put it in your include files before any system headers are
> included.
I've put it at the top of each C file before anything else. Is there any
difference between that and using the compile line command? Any advantages or
disadvantages either way?
Thanks David. I appreciate the explanation.
Poster Matt
Ok I've got it now. I had thought it was to stop _XOPEN_SOURCE from being
defined multiple times within the same source code modules. I've removed the
#ifndef...#endifs and left just the #define bit at the top of each C file.
Cheers Ben. :)
David Schwartz
> I've put it at the top of each C file before anything else. Is there any
> difference between that and using the compile line command? Any advantages or
> disadvantages either way?
The advantages and disadvantages are pretty minor. The advantage of
putting it in the compile command is you don't have to put it in all
your files and you don't have to worry about accidentally leaving it
out of one file. The disadvantage of putting it in the compile command
is that when a new version of the standard comes out, and you want to
use features from it, you have to upgrade your whole project to make
sure it conforms to the new standard. However, a common reply is that
that's yet another advantage, since you really should do that anyway.
Personally, I put it in my list of standard flags and accept that when
a new standard revision comes out, my entire project will need to be
upgraded as a unit. Almost always, the upgrade consists of nothing at
all. Though, for example, if I had had a function called 'nftw', I
would have had to rename it. (But I would argue that as soon as you
know there's a standard function with that name, you'd want to rename
your function anyway. The duplicate name would be confusing to anyone
looking at the code even if it worked fine.)
> Thanks David. I appreciate the explanation.
You're welcome.
DS
Poster Matt
Many thanks (again) for a perfectly expressed explanation. :)
Cheers,
Matt