[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Invalid memory reads in first_non_fsm_start_char_cstring (utf_validate.c)

From: Branko Čibej <brane_at_apache.org>
Date: Sat, 26 Dec 2015 12:08:12 +0100

On 19.12.2015 00:03, Hanno Böck wrote:
> Hi,
> I recently tested to compile subversion with address sanitizer and it
> would immediately show a global out of bounds read when showing the
> help screen (svn help).
> I actually was surprised that this seems to be semi-intentional. The
> code in utf_validate.c has a comment stating that this reads
> uninitialized bytes and there is an #ifdef option to disable it.
> I think this is bad programming behavior and shouldn't be done in
> production code. Reading invalid memory is undefined behavior in C,
> therefore you cannot rely on that your software will function properly
> when using such code.

There's a world of difference between invalid memory and uninitialized
memory. In this case the memory is both valid (i.e., known to be
allocated within the process) and properly aligned. The fact that it may
not have been explicitly initialized does not affect the correctness of
the code; there's no undefined behaviour being invoked here. The code
relies on the fact that the size of allocated buffers is a multiple of
the machine word size, which happens to be true for the APR pools we
use; so there's no question of reading beyond the end of the allocated area.

You're of course free to define SVN_UTF_NO_UNINITIALISED_ACCESS when you
compile Subversion; this will trade performance for a more strict
definition of correctness.

That said, we're always interested in the results memory checking tests.

-- Brane
Received on 2015-12-26 12:08:10 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.