OpenBSD gcc warnings

General
1

I understand that this isn’t really a supported platform, but bear with me…

Using GNAT 11.2.0 built on the latest OpenBSD snapshot from their ports tree, I get the following warnings when compiling anything that links libgnat (line breaks added for readability):

adaint.c:572(adaint.o:(__gnat_try_lock) in archive /usr/local/lib/gcc/x86_64-unknown-openbsd7.3/11.2.0/adalib/libgnat.a):
warning: sprintf() is often misused, please use snprintf()
adaint.c:745(adaint.o:(__gnat_os_filename) in archive /usr/local/lib/gcc/x86_64-unknown-openbsd7.3/11.2.0/adalib/libgnat.a):
warning: strcpy() is almost always misused, please use strlcpy()
adaint.c:1358(adaint.o:(__gnat_readdir) in archive /usr/local/lib/gcc/x86_64-unknown-openbsd7.3/11.2.0/adalib/libgnat.a):
warning: stpcpy() is dangerous; do not use it
cstreams.c:253(cstreams.o:(__gnat_full_name) in archive /usr/local/lib/gcc/x86_64-unknown-openbsd7.3/11.2.0/adalib/libgnat.a):
warning: strcat() is almost always misused, please use strlcat()

I believe that this is good advice. strcat, strcpy, and sprintf are well known as sources of unsafe memory access.
CWE-158: Improper Neutralization of Null Byte or NUL Character
CWE-170: Improper Null Termination
CWE-676: Use of Potentially Dangerous Function

The Ada code calling into these functions does correctly allocate these buffers on the stack and initializes them with zeroes, and most of them pass a pointer to a length variable, initialized with the size of the buffer, to be updated with the length of the string after it’s value is determined.

Does it make sense to eliminate usage of these unsafe functions from libgnat, or am I overreacting? I’m working on a patch that fixes the few warnings I’ve run into, but I’m not sure how far this should go.

1 Like
2

Apparently the strlcpy and strlcat functions are not available in glibc, which is why they aren’t used in gcc. There’s more discussion of the situation here:

3

If you want your patches to be accepted you should ask your question on the gcc mailing list.

See GCC mailing lists - GNU Project, the entry for gcc: gcc is a high volume list for general development discussions about GCC. Anything relevant to the development or testing of GCC and not covered by other mailing lists is suitable for discussion here.

4

I could be wrong but is this still the case? I thought glibc had finally seen the light a couple of years back but they might have added different functions or just one or two of the better alternatives which may not be of much help?

Edit: Seems not :roll_eyes:. It would be great if Linux switched to Musl generally but I can’t see that happening any time soon.

5

Apple did a similar thing with the macOS13 SDK: 107568 – Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.