On Thu, 14 Nov 2024, Jakub Jelinek wrote: > The patch adjusts builtins (when we have them) corresponding to the APIs > mentioned in the C2Y N3322 paper: > 1) strndup and memset get one nonnull_if_nonzero attribute instead of > nonnull > 2) memcpy, memmove, strncpy, memcmp, strncmp get two nonnull_if_nonzero > attributes instead of nonnull > 3) strncat has nonnull without argument changed to nonnull (1) and > gets one nonnull_if_nonzero for the src argument (maybe it needs > to be clarified in C2Y, but I really think first argument to strncat > and wcsncat shouldn't be NULL even for n == 0, because NULL doesn't > point to NULL terminated string and one can't append anything to it; > and various implementations in the wild including glibc will crash > with NULL first argument (x86_64 avx+ doesn't though) > > Such changes are done also to the _chk suffixed counterparts of the > builtins. > > Furthermore I've changed a couple of builtins for POSIX functions which > aren't covered by ISO C, but I'd expect if/when POSIX incorporates C2Y > it would do the same changes. In particular > > 4) strnlen gets one nonnull_if_nonzero instead of nonnull > 5) mempcpy and stpncpy get two nonnull_if_nonzero instead of nonnull > and lose returns_nonnull attribute; this is kind of unfortunate > but I think in the spirit of N3322 mempcpy (NULL, src, 0) should > return NULL (i.e. dest + n aka NULL + 0, now valid) and it is hard to > express returns non-NULL if first argument is non-NULL or third argument > is non-zero
This seems right. > I'm not really sure about fread/fwrite, N3322 doesn't mention those, > can the first argument be NULL if third argument is 0? What about > if second argument is 0? Can the fourth argument be NULL in such cases? They definitely aren't covered by N3322 given that it's only amending certain subclauses of clause 7 (narrow and wide string functions and sorting and searching functions). So the requirement for pointer arguments to be valid still applies. There is the related question of whether sizes for fread and fwrite (and POSIX read and write, etc.) can be larger than the buffer size if it's known that the amount of data that can actually be read or written fits within the buffer. See glibc bug 19165, where it turned out that the Linux kernel rejects too large buffer sizes for read with EFAULT regardless of the amount of data that might turn out to be available (so too-large sizes certainly can't work in practice at present). This patch is OK. -- Joseph S. Myers josmy...@redhat.com
