On an unrelated note, Please lets use autoconf like macros set up in an
appropriate config file rather than compiler or OS checking in the source
file, not compiler version checking in the source files. WIN32 != MSVC.
We should for all contingencies. IOW lets not assume every compiler but
visual C has strdup and only visual C has _strdup, and that every machine
has one or the other. The logic for function choice can be complicated
and should not be replicated in multiple source files unless absolutely
necessary. Best if it's in two places and only two places... the
configure script and boinc_win.h. Otherwise our code gets littered with
"#if defined(_MSC_VER) || (defined(__MINGW32__) && MINGW32_PREREQ(3,11)) ||
(defined(__GNUC__) && (GNUC < 4))"
in boinc_win.h there should be
#if defined(_MSC_VER) // better yet would be _MSC_VER_FULL >= version_num
#undef HAVE_STRDUP
#define HAVE__STRDUP 1
#endif
On every non-MSVC system, in config.h, configure will define HAVE_STRDUP
and HAVE__STRDUP appropriately. Then safe_copy becomes
char *safe_copy(const char *cstr) {
#if defined(HAVE_STRDUP)
return strdup(cstr);
#elif defined(HAVE__STRDUP)
return _strdup(cstr);
#else
char *s=malloc(strlen(cstr)+1);
if (s) strcpy(s,cstr);
return s;
#endif
}
Or we could code missing standard functions like strdup into std_fixes.h,
although that was originally workarounds for old g++ and MSVC bugs that are
probably no longer necessary.
On Wed, Jan 4, 2017 at 11:37 AM, Christian Beer <[email protected]>
wrote:
> On 04.01.2017 16:36, Juha Sointusalo wrote:
> > On 4 January 2017 at 02:24, Artem Vorotnikov <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > For the record, strdup() is *not* standard, it is a GNU extension and
> > not part of ANSI/ISO C.
> >
> >
> > It is in POSIX. MSVC knows it as _strdup() .
>
> It would still work by doing something like this:
>
> safe_copy(cstr){
> #ifdef MSVC
> return _strdup(cstr);
> #else
> return strdup(cstr);
> #endif
> }
>
> which would encapsulate the platform specific implementation nicely. But
> it would still allocate memory. But that was not my point in the beginning.
>
> I accept all reasons given in this email thread about why this function
> is problematic and maybe should be discussed. The reason I'm not willing
> to accept is the one given in the commit message. Just because something
> is producing warnings on one platform is not justification enough to
> remove it. That was the point I wanted to bring across.
>
> Regards
> Christian
>
> _______________________________________________
> boinc_dev mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
--
Eric Korpela
[email protected]
AST:7731^29u18e3
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
