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

Re: svn commit: r1308966 - in /subversion/trunk/subversion: include/svn_string.h libsvn_subr/svn_string.c

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 03 Apr 2012 16:51:24 +0100

julianfoad_at_apache.org writes:

> Author: julianfoad
> Date: Tue Apr 3 15:03:56 2012
> New Revision: 1308966
>
> URL: http://svn.apache.org/viewvc?rev=1308966&view=rev
> Log:
> Make svn_stringbuf_ensure() allocate an additional byte for the null
> terminator, bringing it in line with svn_stringbuf_create_ensure() which
> always had those semantics. Some callers had been expecting this behaviour,
> and thus had been buggy. This will make buggy callers just work, and any
> callers that were already adding one byte will still work whether they get
> updated or not. It would now be an error to link code written against the
> new API to a library containing an old implementation of the function.

> -/** Make sure that the string @a str has at least @a minimum_size bytes of
> - * space available in the memory block.
> +/** Make sure that the string @a str has allocated at least enough space
> + * to hold a string of length @a minimum_size bytes (as well as the
> + * terminating null character).
> *
> - * (@a minimum_size should include space for the terminating NULL character.)
> + * @note: Before Subversion 1.8, the caller was supposed to include one
> + * byte for the null terminator in the value of @a minimum_size.
> */

But it's not a compile-time error, it's a run-time error if the buffer
overrun happens to hit important memory. But it's quite possible that
most of the time the buffer overrun will hit memory that is allocated
but unused meaning the error will be hidden until the memory usage is
just right to trigger the bug. To write robust code the caller still
has to pass len+1, or explicitly test the Subversion minor version.
What are we going to recommend that users of the API do?

The discussions we had earlier this year were

http://mail-archives.apache.org/mod_mbox/subversion-dev/201202.mbox/%3C1329222414.71999.YahooMailNeo@web86701.mail.ird.yahoo.com%3E

http://mail-archives.apache.org/mod_mbox/subversion-dev/201202.mbox/%3CCABD8fLWJLjcawY0Db5DyPNb6A5CdTryMOj4y+rH_yMsYeVz8+g@mail.gmail.com%3E

-- 
Philip
Received on 2012-04-03 17:52:04 CEST

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