Re: [VOLK] Release 3.3.0

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