runtime: use the preferred spelling on Windows (NFCI)

[compnerd]

This changes the windows path to use the preferred _strdup over strdup to avoid the deprecation warning.

[compnerd]

@swift-ci please smoke test

[compnerd]

@swift-ci please smoke test macOS platform

[al45tair]

@compnerd Do you think it would be worthwhile doing

#ifdef _WIN32
#define strdup _strdup
#define open _open
#define close _close
// ... and so on ...
#endif

in a header somewhere rather than putting conditionals around uses of these functions?

[compnerd]

@compnerd Do you think it would be worthwhile doing

#ifdef _WIN32

#define strdup _strdup

#define open _open

#define close _close

// ... and so on ...

#endif

in a header somewhere rather than putting conditionals around uses of these functions?

That can be tempting but they are not always identical. Furthermore, use of _open is a bad idea as it introduces a security issue as well as runtime deficiencies. We should use _wopen which takes a UCS-2/UTF-16 encoded path, which will break open. It's better to conditionalize the use sites IMO.

[al45tair]

That can be tempting but they are not always identical.

In practice though many of them, and strdup()/_strdup() is an excellent example here, are identical, which isn't surprising because they were added to DOS compilers back in the day for exactly that reason. So we could do this at least for the ones that are actually identical, or near enough that nobody cares about the differences.

I take your point about _open() vs _wopen(). We could perhaps do

static inline int open(const char *name, ...) __attribute__((unavailable("open() is not a good idea on Windows; please use _wopen() instead"))) {
  return -1;
}

or similar to make it obvious what the problem is.