Re: svn commit: r1902206 - /apr/apr/trunk/encoding/apr_base64.c

[Ruediger Pluem <rp...@apache.org>]

On 6/24/22 11:56 AM, Yann Ylavic wrote:
> On Thu, Jun 23, 2022 at 8:50 PM Ruediger Pluem <rp...@apache.org> wrote:
>>
>> On 6/23/22 5:12 PM, ylavic@apache.org wrote:
>>>
>>> +/* Above APR_BASE64_ENCODE_MAX length the encoding can't fit in an int >= 0 */
>>> +#define APR_BASE64_ENCODE_MAX 1610612733
>>> +
>>> +/* Above APR_BASE64_DECODE_MAX length the decoding can't fit in an int >= 0 */
>>> +#define APR_BASE64_DECODE_MAX 2863311524u
>>> +
>>
>> Doesn't this depend on the storage size of int on the respective architecture and thus
>> should be derived from INT_MAX?
> 
> There is no APR_INT_MAX unfortunately, I could do something like:
> 
> #if APR_HAVE_STDINT_H /* C99, but maintainer-mode is C89 */
> #include <stdint.h>
> #define APR_BASE64_LEN_MAX INT_MAX
> #else
> #define APR_BASE64_LEN_MAX APR_INT32_MAX
> #endif
> 
> and use APR_BASE64_LEN_MAX instead of APR_INT32_MAX here and there,
> but I doubt there are any architectures (we care about) where
> sizeof(int) != 4.
> I don't think we support < 32bit archs, do we?
> For >= 32bit archs, of the 5 data models (LP32, ILP32, ILP64, LLP64
> and LP64), only LP32 (i.e. WIN16 API, Apple Macintosh) and ILP64 ([1]
> mentions HAL Computer Systems port of Solaris to the SPARC64) don't
> have 32bit ints, and I don't think we care about those either.
> 
> So we should be safe assuming ints are 32bit?

Given your explanations about I tend to say yes. Thanks for the details.

Regards

Rüdiger