The doc for snprintf says:

n - Maximum number of bytes to be used in the buffer.
The generated string has a length of at most n-1, leaving space for the additional terminating null character.

So I don't think this patch is correct.

If you have a suggestion on how to properly handle, I'll happily merge it into this branch.
I was looking for the minimal change to get this to compile without warning. I believe that this PR achieves that goal without making the behavior more wrong than before

Since we do want n characters to be written (and not n-1) the patch is changing (and in my opinion breaking) the behavior.

If we do rely on truncating the data then the code should explicitly check the return value (in which case I would expect the warning to disappear).

Thanks @dirk-thomas for the explanation. I modified the patch to actually write all characters provided by the user / test and not n - 1

Without this patch: (temporary job)

GNU C Compiler Warnings: 3 warnings.
3 new warnings


test_interfaces.cpp:285, GNU C Compiler 4 (gcc), Priority: Normal
‘__builtin___snprintf_chk’ output truncated before the last format character [-Wformat-truncation=]

test_interfaces.cpp:337, GNU C Compiler 4 (gcc), Priority: Normal
‘__builtin___snprintf_chk’ output truncated before the last format character [-Wformat-truncation=]

test_interfaces.cpp:579, GNU C Compiler 4 (gcc), Priority: Normal
‘__builtin___snprintf_chk’ output truncated before the last format character [-Wformat-truncation=]

With this patch: (temporary job)

GNU C Compiler Warnings: 0 warnings.
3 fixed warnings

And CI on our regular jobs/platforms to make sure this doesnt break anything:

• Linux
• Linux-aarch64
• macOS
• Windows