Is there any interest in C housekeeping PR?

[ChooseAfferoGPL]

A quick grep turned up hits for things like strcpy() and sprintf() (mostly in test/). Is there any interest in PR for migrating to things like strncpy() and snprintf(), for a smaller attack surface?

[attipaci]

Thanks for the suggestion. PR #284 changes strcpy() to strncpy() -- good call. However, changing sprintf() to snprintf() is not so straightforward, since snprintf() is not as portable (e.g. MacOS, MSC, or older platforms like LynxOS 3.1 [which is important to us]). Feel free to try a PR, however, if you think the portability issue can be managed.

[attipaci]

PS. As far as I can tell, the sprintf() calls are are bounded inside the library. I.e., they either print into appropriately sized internal buffers, or else specifically state the minimum required size for buffer parameters (e.g. novas_print_timescale() which requires that the buffer parameter has storage space for at least 4 bytes). It's true that the test, benchmark, or build helpers programs can, in principle, overflow on sprintf(), but these are not part of the runtime, so I'm not too concerned about it.

[ChooseAfferoGPL]

TIL Apple snprintf() is complicated. Plot twist, macOS is deprecating sprintf()?

Having just started to learn the SuperNOVAS API, and not up on the latest cross platform C trivia, perhaps sending security related PRs should go on a back burner.

[attipaci]

TIL Apple snprintf() is complicated. Plot twist, macOS is deprecating sprintf()?

I think the deprecation affects only Objective-C, not standard C (at least that's the way I understood it). So we should be fine there...