[Bug analyzer/114472] [14 Regression] ICE: in falls_short_of_p, at analyzer/store.cc:365 (in exceeds_p, at analyzer/store.cc:342) with -fanalyzer

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114472

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
strncpy (..., -1) is an always UB case; the testcase has UB already on &s - 3,
but get_next_bit_offset of -32 suggests that it is somehow adding the -3 *
BITS_PER_UNIT offset from the source and the -1 * BITS_PER_UNIT from the size. 
That is wrong,
first of all, strncpy from the source copies just at most that many bytes, in a
valid program there would need to be a '\0' far before that as one can't do
pointer arithmetics in char * past half of the address space; plus the size
isn't negative, it is positive 0xffffffffffffffffULL on x86-64.
The reason strncpy would be UB with [LONG_MAX + 1UL, ULONG_MAX] last argument
is that it then has to fill the rest of the buffer with '\0's and again the
pointer arithmetics isn't well defined in that case.