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

Closed
e5ten wants to merge 1 commits from e5ten/bc:no-xsi into master
e5ten commented 2 years ago

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

supercedes #1, keeps POSIX version at 2001, removes XSI requirement.
e5ten changed title from replace strdup use with malloc+memcpy, to _XOPEN_SOURCE requirement to replace strdup use with malloc+memcpy, to remove _XOPEN_SOURCE 2 years ago
Poster

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.

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.
Owner

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.

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.
Poster

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.

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.
Owner

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.

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()`][1]. 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. [1]: https://www.vanheusden.com/misc/strdup/strdup_v_SlMalMemc.php
Poster

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

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
Owner

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

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

But you would still need the XSI define for strdup?

But you would still need the XSI define for strdup?
Owner

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

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

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.

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.
Owner

Fair enough. Let's do that then.

Fair enough. Let's do that then.
Poster

I've reopened my previous PR that did that.

I've reopened my previous PR that did that.
e5ten closed this pull request 2 years ago
Please reopen this pull request to perform a merge.
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.