# repository

lower_name: bc
name: bc
default_branch: master
owner_name: gavin
description:
An implementation of Unix dc and POSIX bc with GNU and BSD extensions. Finished, but well-maintained.


# issue

name: bump _POSIX_C_SOURCE to 200809L, remove _XOPEN_SOURCE
content:
With the previous `_POSIX_C_SOURCE=200112L`, strdup was the only function that was unavailable without `_XOPEN_SOURCE=600`, increase `_POSIX_C_SOURCE` version to make it so `_XOPEN_SOURCE` can be removed and the source can be completely POSIX compatible.


name: `locale_install.sh` fails to install many locales
content:
Hi Gavin,

In `locale_install.sh`, it lists all installed locales with `locale -a`, then tries to match all `.msg` files in `locales` with them.  If one `.msg` files matches a installed locale, it will be installed.

Unfortunately, on my LFS development system (with glibc-2.31) `locale -a` outputs the locale names like `zh_CN.utf8`, but the corresponding `.msg` file is `zh_CN.UTF-8.msg`.  Then it just won't be installed.

I can create a symlink `zh_CN.utf8.msg` to `zh_CN.UTF-8.msg` to make `locale_install.sh` install it.   But I'm not sure if it's the best way to solve this problem.  (This is just an example, there are many other mismatches like `en_US.ISO8859-1.msg` versus `en_US.iso88591`, etc.)


name: fix buggy format string in zh_CN.UTF-8.msg
content:
Several strings in `zh_CN.UTF-8.msg` are buggy.  The most alerming one is the translation of

~~~~~
6 "invalid command-line option: \"%s\""
~~~~~

The translation in `zh_CN.UTF-8.msg` is:

~~~~~
6 "无效的命令行选项：'%c'(\"%s\")"
~~~~~

We can see the format string is not matched.  This causes `make test` fail (`dc` crashes).

I think we should add a `locale_check.sh`, to check if all format strings in translations match to the original English string.  But I'm too lazy to do that, at least for now :).


name: Passify a new clang warning.
content:

Clang 12 warns about certain cases of string concatenation in array
initialization.  Adding parentheses siliences this warning.


name: Avoid clobbering `r` variable in Bessel function
content:

The `j` function uses `r` to accumulate its result, but did not
declare it with auto, causing the caller's value to be clobbered.

To fix this, declare `r` as auto to make it a local variable.


name: syntax error near unexpected token `)'
content:
For bc-3.2.5, runing 'sh configure.sh' I get👍 

configure.sh: line 612: syntax error near unexpected token `)'
configure.sh: line 612: `                               disable-extra-math*)'


name: Please stop updating copyright notices
content:
There is no legal reason to update a copyright notice: your copyright will subsist until you are seventy years dead and then cease.  People who understand what _finished_ means shouldn't need to look at a copyright date either.  So what you are doing is making changes for the sake of making changes, which is just as bad in the comments as in the code.


name: Seg fault in make check
ref: refs/heads/master
content:
I use your AUR PKGBUILD. Obviously the executable doesn't have debugging symbols, but I can figure out how to compile with them if you need.
```
Running bc errors..../tests/errors.sh: line 101: 107555 Done                    printf '%s\n' "$line"
     107556 Segmentation fault      (core dumped) | "$exe" "$@" "$options" 2> "$out" > /dev/null

bc crashed (139) on test:

    j(1,2,3)
make: *** [Makefile:349: test_bc_error_lines] Error 139
```


# comment

content:
Alternatively, if you would prefer the POSIX requirement stay at 2001, I could just replace the one actual strdup call with a malloc+memcpy, and then `_POSIX_C_SOURCE=200112L` without `_XOPEN_SOURCE` will be sufficient.


content:
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.


content:
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.


content:
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.


content:
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


content:
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


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


content:
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.


commit_sha: a054de4b1e6dc61e493de72176faf0aa7236a5d3
content:
<a href="/gavin/bc/commit/a054de4b1e6dc61e493de72176faf0aa7236a5d3">Merge pull request #1

Pull request description:

&gt; bump _POSIX_C_SOURCE to 200809L, remove _XOPEN_SOURCE&#39; (#1)
&gt; from e5ten/bc:posix-c into master
</a>


content:
Oh, I should note that even though I have made improvements to `bc` apart from this PR, I won't be releasing a new version for a while. Expect about two or three months.


content:
So...it turns out that `LONG_BIT` is also under X/Open System Interfaces. And I need this one because it defaults to the minimum of 32 if it doesn't exist.

Because of that, I have to undo this PR merge and go back to using XSI. And since I am doing that, might as well go back to POSIX 2001 and XSI 600.


content:
Symlinks are best, yes. I don't add them until someone asks because I don't know what is needed.

I have added a symlink to zh_CN.utf8. Do you need me to do a release? Also, are there other symlinks you want?


content:
It's not critical so I can wait for the next release.

I only use zh_CN.utf8 locale (besides the well-known locales `C` or `en_US.utf8`).  But as recent glibc version's `locale -a` only outputs `utf8` instead of `UTF-8` now, each `UTF-8` should be added an `utf8` symlink (IMO).  For example, `es_ES.utf8.msg`, `ja_JP.utf8.msg`, etc.


content:
Okay, I have added all of the `utf8` locales. It was big enough of a change that I decided to release `3.0.2`.

I am closing this now; please reopen if there is more I need to do.


content:
Thank you for the report and the code. I will commit this when I get home. I will also check all of the messages in Chinese.


commit_sha: 9cb586fc2981bc6813b685d6b136cbdb00504109
content:
<a href="/gavin/bc/commit/9cb586fc2981bc6813b685d6b136cbdb00504109">Merge pull request &#39;fix buggy format string in zh_CN.UTF-8.msg&#39; (#5) from xry111/bc:xry111-patch-1 into master
</a>


content:
Thank you for the fix. It has been merged, and I will be pushing fixes for the rest of the Chinese locales soon.


content:
I encountered this compiling FreeBSD-CURRENT with the latest llvm-devel port (a snapshot dated 2020-09-25).


commit_sha: 07f80644ddb4ec93f4bd1e1455aad65cb57bcb6c
content:
<a href="/gavin/bc/commit/07f80644ddb4ec93f4bd1e1455aad65cb57bcb6c">Merge pull request &#39;Passify a new clang warning.&#39; (#6) from brooksdavis/bc:bugprone-suspicious-missing-comma into master

Reviewed-on: https://git.yzena.com/gavin/bc/pulls/6
</a>


content:
Thank you very much. And thanks for reporting it to FreeBSD also; the package maintainer over there and I were in contact.


commit_sha: 021527d2bcbf531534fc344e8be4b250bb16c6d0
content:
<a href="/gavin/bc/commit/021527d2bcbf531534fc344e8be4b250bb16c6d0">Merge pull request &#39;Avoid clobbering `r` variable in Bessel function&#39; (#7) from mcf/bc:bessel into master

Reviewed-on: https://git.yzena.com/gavin/bc/pulls/7
</a>


content:
Sorry, I didn't mean that what you did wasn't valuable. I obviously didn't catch it.

What I meant is that is was obvious that your fix was good.

Words...


content:
@bdubbs thank you for the report. My shell did not warn me about this one, unfortunately. The shell in my Linux distro is not good.

Fortunately for you, FreeBSD already told me about this, and there is a `3.2.6` release out with a fix.

Please check out `3.2.6` and close this issue if it works for you. Otherwise, please let me know.

I apologize for the broken release.


content:
This is a surprising bug report. I don't really know how to react.

I didn't make the change just for the sake of changes; I made the changes at the same time I made other changes.

I understand your position though. Can you give me a concrete way that this has hurt you?


content:
After further consideration, it seems like your bug report is not made in good faith. You can reopen with a proper concrete example of how it hurt you, but otherwise, I am just going to close this.


content:
Yeah, that is not good, but I think I have an idea of where the problem is.

First, what locale are you using? If it's not the C locale, I suspect the problem is because I changed error messages.

If so, could you build my bc by hand and install it, then run `make check`? If it passes, then the problem is because the test suite is running against the installed locale files rather than the new locale files (I had to add some error messages).

Honestly, though, I don't know how to fix the PKGBUILD if it is using the old locale files. Maybe I need to force using the C locale during `make check`.


content:
@brodygoat, I have edited the `PKGBUILD` to set `LANG=C` and `LC_ALL=C`. Could you see if this solves your problem?


content:
Oh I didn't realize I wouldn't get email notifications. Yeah, that worked @kseistrup. That seems a reasonable change in the PKGBUILD. 

So your changes don't work with unicode, @gavin?

Also I didn't realize someone else had taken up the AUR package maintainer role. I would have submitted this there first. 


content:
My changes do work with Unicode. However, POSIX locales are fundamentally broken, and that is where the issue is.

In the [development manual Locales section][1], I talk about how POSIX locales use `$NLSPATH` to find locales. This is the only way to access locale data for a program such as `bc`, so it means that the *non-installed* `bc` being tested in the package always tries to access the *installed* locale files.

This is generally not a problem, as the locale files do not change often; in fact, they only change when I need to add error messages.

And even that would not be a problem if the error messages were not used as format strings for `printf()`.

And even *that* would not be a problem if the error messages used the same format specifiers.

However, they do not. Some error messages use format specifiers (they need extra data), and some do not. This means that when error messages get added, the installed locales may have an error message with a format specifier that expects extra arguments, but the non-installed locale does not. So when the `bc` is under test, it is assuming that its locale is installed. In this case, that was not true, and `printf()` tried to grab a function argument that wasn't there. Hence, you got a segfault.

However, once you actually install `bc`, you will be able to use Unicode without issue because the package will have installed the new locales along with the newly-installed `bc`, and `printf()` will be given the correct error message, which means that it won't try to pull in arguments that are not there.

Does that make sense?

[1]: https://git.yzena.com/gavin/bc/src/branch/master/manuals/development.md#locales-1


content:
@brodygoat PS: I have steeped in as co-maintainer of the AUR package since @gavin doesn't use ArchLinux.


