CGRAN website SSL certificate is expired.

Hello.

I just thought you should know that the SSL certificate for cgran.org is expired.

Re: [VOLK] Release 3.3.0

Marcus Müller <mmueller@gnuradio.org> writes:

> would you mind giving https://github.com/gnuradio/volk/pull/813 a try on your machine, please?

I commented in the PR, but it applies to 3.3.0, builds under pkgsrc with
gcc 10, and passes tests. Looks good to merge from my viewpoint.

Re: [VOLK] Release 3.3.0

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

Re: [VOLK] Release 3.3.0

Marcus Müller <mmueller@gnuradio.org> writes:

> place. I'll make a PR to that end; if you could test that, Greg, it'd
> be much appreciated.

Sure, please feel free to @gdt (github and codeberg) or email me a link
and I'll try it.

Johannes: I realize that having bougght into github CI that it's not a
great portability situation as the set of available runners is very
limited. I am struggling with this myself on an unrelated project, but
so far more inclined to put energy into leaving github and some
beyond-github future CI more than improving CI on github, even if it's
not so much either way :-(


Someone else updated volk to 3.3.0 and here's the patch they arrived at.
I'm not a fan of doing it this way (upstream), but it does more or less
show the issue well.



--- include/volk/volk_common.h.orig 2026-02-09 12:27:43.544508041 +0000
+++ include/volk/volk_common.h
@@ -150,7 +150,12 @@ union bit256 {
////////////////////////////////////////////////////////////////////////
// log2f
////////////////////////////////////////////////////////////////////////
+#ifdef __cplusplus
+#include <cmath>
+using std::isinf, std::isnan;
+#else
#include <math.h>
+

Re: [VOLK] Release 3.3.0

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

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

Re: [VOLK] Release 3.3.0

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.