On 06/05/2018 06:39 PM, Eric Gallager wrote:
On 6/5/18, Martin Sebor <mse...@gmail.com> wrote:
The attached patch adds basic support for handling strnlen
as a built-in function. It touches the strlen pass where
it folds constant results of the function, and builtins.c
to add simple support for expanding strnlen calls with known
results. It also changes calls.c to detect excessive bounds
to the function and unsafe calls with arguments declared
attribute nonstring.
A side-effect of the strlen change I should call out is that
strlen() calls to all zero-length arrays that aren't considered
flexible array members (i.e., internal members or non-members)
are folded into zero. No warning is issued for such invalid
uses of zero-length arrays but based on the responses to my
question Re: aliasing between internal zero-length-arrays and
other members(*) it sounds like one would be appropriate.
I will see about adding one in a separate patch.
Martin
[*] https://gcc.gnu.org/ml/gcc/2018-06/msg00046.html
I see stuff in the patch mentioning the library version of strnlen;
have you tested on platforms both with and without strnlen in their
libcs? The gnulib documentation lists these platforms as having
missing or buggy strnlens:
This function is missing on some platforms: Mac OS X 10.5, FreeBSD
6.0, NetBSD 5.0, OpenBSD 3.8, AIX 4.3.2, HP-UX 11, IRIX 6.5, OSF/1
5.1, Solaris 10, mingw, Interix 3.5.
This function is buggy on some platforms: AIX 4.3.
https://www.gnu.org/software/gnulib/manual/html_node/strnlen.html
The patch doesn't make GCC synthesize calls to strnlen if they
don't appear in source code. It's the responsibility of
programmers for those targets to work around their limitations,
bugs, or absence of support for the function (e.g., by avoiding
making calls to it). This is the same as for most other library
functions, except a few exceptions like memcpy and memset where
GCC relies on the target to provide conforming implementations.
I only tested the patch on x86_64-linux.
Martin
