replace strdup use with malloc+memcpy, to remove _XOPEN_SOURCE #2

supercedes #1, keeps POSIX version at 2001, removes XSI requirement.

This actually allows the source to compile with _POSIX_C_SOURCE=1 if you want.
EDIT: nevermind, I had certain functionality disabled that uses stuff present with _POSIX_C_SOURCE=200112L but not _POSIX_C_SOURCE=1.
EDIT 2: specifically, the only thing that needs _POSIX_C_SOURCE=200112L and isn't available with _POSIX_C_SOURCE=1 is pselect, and subsequently the timespec struct used by it.

Thank you for your PR. Can you tell me a little more about why you would like to remove the XSI requirement? Is it making it difficult for you to build on your platform?

Also, be aware that technically, c99, a requirement for bc, is part of XSI, so I am not sure the requirement could be removed. However, I would love to hear why you want it removed.

It hasn't caused me any build trouble at all, I'm on a very normal platform. I just thought it could be preferable to make the build completely POSIX compliant, if possible. In regards to c99, it isn't an XSI extension, it's part of the CD (C development utilities) option group, which is pretty much needed for C programs, like bc. A similar option group that is also technically optional functionality is the SD (software development utilities) group, which make that bc also requires is a part of. As far as I can tell the only thing requiring the XSI option group in this project is that one strdup use the PR replaces.

I have done some research and confirmed what you said about c99 being part of the CD group.

That said, this is a hard decision. I found some benchmarks that show that strdup() can be faster than strlen()/malloc()/memcpy(). Note that it is not in most cases, but it is always the same or better.

I am also not sure that this requirement is a burden in practice since strdup() is also technically required by POSIX 2008 base and XSI also requires c99 and make. I mean, I could move back to requiring POSIX 2008, but I also admit that I would be surprised if there was a platform that did not support XSI 2001.

I don't know. I will have to think about this one. I will keep it open in the meantime.

Fair enough. In regards to speed I just checked glibc, musl, and freebsd's libc's implementations of strdup, and they all do strlen+malloc+memcpy, so I would expect that's the case in most places and there shouldn't be a significant speed difference.
EDIT: same for openbsd's libc, uclibc{,-ng}, and bionic

After considering this, I think it would be better to just change the requirements from POSIX 2001 and XSI to POSIX 2001 and strdup().

But you would still need the XSI define for strdup?

I would, yes. Hmm...back to thinking again.

imo if you don't want to replace the strdup, I think POSIX 2008 would be a better requirement than POSIX and XSI 2001, because a POSIX compliant would have to be 12 years out of date to not support POSIX 2008, but a hypothetical OS seeking purely to comply to POSIX could potentially never end up complying to XSI 2001 or supporting the define.

Fair enough. Let's do that then.

I've reopened my previous PR that did that.