On Thu, 17 Dec 2009, David Knezevic wrote:
> Kirk, Benjamin (JSC-EG311) wrote:
>> Pretty sure that is only guaranteed to work if you use std::strncpy - cstring should include strncpy inside the
>> std:: namespace. Perhaps the implementation for your compiler does not strictly enforce that which is why the
> > code sniipet works?
> Yeah, I guess the version of gcc that I'm using doesn't strictly enforce
> Roy Stogner wrote:
> > I'll change getpot.h to use std:: where applicable.
> Are you still planning to do this Roy? I see that you added <cstring>,
> but it sounds like we still need the extra std:: for maximum
> portability, no?
Looking over what's required for maximum portability worries me. In
particular, GetPot is using strtok_r and snprintf. The former is part
of some Thread Safe Functions extension to the C standard. It's in
string.h whenever _SVID_SOURCE || _BSD_SOURCE || _POSIX_C_SOURCE >= 1
|| _XOPEN_SOURCE || _POSIX_SOURCE are defined, which is about as
portable as you can get without being ISO C, but I'm not sure how the
"rules" for that extend to C++. The latter is defined for _BSD_SOURCE
|| _XOPEN_SOURCE >= 500 || _ISOC99_SOURCE, even more iffy.
I think the most portable thing to do is replace snprintf with
ostringstream based conversion and replace strtok_r with string::
methods, but I'm not going to get to that right away, and I'm not
going to bother making us 100% cstring namespace compliant until
I'm sure that's the weakest link in the file.