Hello Greg,
would you mind giving https://github.com/gnuradio/volk/pull/813 a try on your
machine, please?
Hello Johannes,
sadly I could not find a way that both introduces no random new includes in volk_common.h
that causes functional changes in consumers of the header, while still addressing the
issue Greg describes; the cleanest seems to be moving the mostly-internal math functions
out of volk_common.h to a new header.
That of course means API breakage; sorry.
Best regards,
Marcus
On 2026-02-09 5:39 PM, Marcus Müller wrote:
hm that volk_common.h is generally not that well-structured; I'd advocate for having
something like `volk_cos_poly` in a different file than basic type and attribute
declarations that get used all over the place. I'll make a PR to that end; if you could
test that, Greg, it'd be much appreciated.
Best regards,
Marcus
On 2026-02-08 8:57 PM, Greg Troxel wrote:
Johannes Sterz Demel <[email protected]> writes:
Hey Greg,
thanks for picking up the release so quickly. I haven't seen this issue
with any of the CI compilers.
Would there be a way to reproduce that in a docker container?
You could add NetBSD 10 the CI farm. (I am not clear on how docker
works.)
It seems this is pretty hard:
https://stackoverflow.com/questions/33770374/why-is-isnan-ambiguous-and-how-to-avoid-it
https://stackoverflow.com/questions/39130040/cmath-hides-isnan-in-math-h-in-c14-c11
https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-
you-might-think
(section "absolute mess")
another possibility is to use __builtin_isnan, which works
on gcc and clang but that's not portable to other compilers that comply
with standards.
From reading lots of things, I have taken away that in C++ code isnan
should always be written std::isnan(), have not found anything
indicating that writing it that way is at all bad, and that it's
unspecified if abs without std:: works or not.
