#define _XOPEN_SOURCE 600 - where to define?
in [Unix Programming]
|
From: Poster Matt on 7 Mar 2010 10:23 David Schwartz wrote: > On Mar 7, 5:15 am, Poster Matt <postermatt(a)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.
From: Poster Matt on 7 Mar 2010 10:27 Ben Bacarisse wrote: > Poster Matt <postermatt(a)no_spam_for_me.org> writes: > >> 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. 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. :)
From: David Schwartz on 7 Mar 2010 12:57 On Mar 7, 7:23 am, Poster Matt <postermatt(a)no_spam_for_me.org> wrote: > 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
From: Poster Matt on 7 Mar 2010 18:40
David Schwartz wrote: > On Mar 7, 7:23 am, Poster Matt <postermatt(a)no_spam_for_me.org> wrote: > >> 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.) Many thanks (again) for a perfectly expressed explanation. :) Cheers, Matt |