> Am 15.04.2022 um 18:20 schrieb Yann Ylavic <ylavic....@gmail.com>:
>
> On Fri, Apr 15, 2022 at 6:19 PM Yann Ylavic <ylavic....@gmail.com> wrote:
>>
>> On Fri, Apr 15, 2022 at 4:21 PM Stefan Eissing <ste...@eissing.org> wrote:
>>>
>>>> Am 15.04.2022 um 15:24 schrieb Yann Ylavic <ylavic....@gmail.com>:
>>>>
>>>> On Wed, Apr 6, 2022 at 11:17 AM <ic...@apache.org> wrote:
>>>>>
>>>>> Modified: httpd/httpd/trunk/server/util.c
>>>>> URL:
>>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util.c?rev=1899609&r1=1899608&r2=1899609&view=diff
>>>>> ==============================================================================
>>>>> --- httpd/httpd/trunk/server/util.c (original)
>>>>> +++ httpd/httpd/trunk/server/util.c Wed Apr 6 09:17:42 2022
>>>>> @@ -2615,7 +2615,7 @@ AP_DECLARE(void) ap_content_type_tolower
>>>>> */
>>>>> AP_DECLARE(char *) ap_escape_quotes(apr_pool_t *p, const char *instring)
>>>>> {
>>>>> - int newlen = 0;
>>>>> + apr_ssize_t extra = 0;
>>>>
>>>> Shouldn't it be an apr_size_t?
>>>
>>> Similar comment raised on the PR https://github.com/apache/httpd/pull/298
>>
>> Oh, I missed it.
>>
>>>
>>> Not totally sure. The thing is that C in general has a problem with
>>> strings where ptrdiff_t (apr_ssize_t) is not sufficient. Allocating
>>> something
>>> larger than ptridff_t leads to undefined behaviour.
>>
>> On 32bit systems, ssize_t = ptrdiff_t = int, I think allocating
>> something larger than INT_MAX is possible if you have the memory
>> available for it.
>>
>>>
>>> So, maybe we should check that "(inchr - instring) + extra + 1" does not
>>> wrap around?
>>
>> Maybe something like:
>> apr_size_t size, extra = 0;
>> ...
>> size = inchr - instring + 1;
>> ap_assert(size + extra > size);
>
> Well, ap_assert(size + extra >= size) of course..
Added in r1899905. Note that the > is sufficient since !extra is checked above.
>
>> size += extra;
>> ?
