This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] string: Add tests for zero length string inputs
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Richard Earnshaw <rearnsha at arm dot com>, Will Newton <will dot newton at linaro dot org>, "Ondr(ej BÃlka" <neleai at seznam dot cz>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 23 Sep 2014 06:57:53 -0700
- Subject: Re: [PATCH] string: Add tests for zero length string inputs
- Authentication-results: sourceware.org; auth=none
- References: <1410910830-20900-1-git-send-email-will dot newton at linaro dot org> <20140919112302 dot GA2912 at domone> <CANu=Dmgn75GZU8my6fcCp1AyJRw8jEJVhaGTD+5mjOrXB_ENGw at mail dot gmail dot com> <542049A4 dot 1070409 at arm dot com> <54206104 dot 7020607 at cs dot ucla dot edu> <54216D4B dot 30505 at arm dot com>
Richard Earnshaw wrote:
if src+1 can point outside of the address space of the program
As Andreas points out, src+1 does not point outside the address space of
the program. It is a valid pointer.
My reading of those sections also leads me to believe that memcpy could
legitimately expect to perform "*(char*)dst = *(char*)dst", even if the
length is zero.
I'm sorry, but this reading is incorrect. If the size is zero, memcpy
cannot store any bytes into the destination. Any memcpy that does
otherwise would break a lot of programs.
I can think of no reason why 7.21.1/2 would explicitly
require valid pointers when the length parameter was 0 unless it was
intended that dereferencing could occur.
It caters to (unusual) architectures that require valid pointers in
address registers even when the pointers are not dereferenced, e.g.,
loading a pointer into an address register will trap if the pointer is