Hey Greg,
Our CI consists of the GitHub runners that are available through this channel. If there's a service to add netbsd runners, please let me know. That'd be a great addition.
Besides, Marcus suggestion to fix things sounds good either way.
Cheers
Johannes
On Mon, 9 Feb 2026, 17:39 Marcus Müller, <mmueller@gnuradio.org> 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 <jdemel@gnuradio.org> 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.
>
>
>
No comments:
Post a Comment