On Mon, Apr 09, 2018 at 08:56:28PM +0200, Tobias Stoeckmann wrote:
> As tb@ pointed out, u64ton can overflow on ULONG_MAX. It could also
> happen on systems with 64 bit int and INT_MIN, although we don't have
> such a system supported by our code base.
> 
> You can reach the u64ton function by printing the length of a string
> within a variable like this:
> 
> $ a=string
> $ echo ${#a}
> 6
> $ _
> 
> Technically there is no need to use BITS(uint64_t) because 20+2 would
> be enough. But it seems that there is a strong preference towards
> going "long long" instead of int64_t due to return types of time()
> and strtonum() as well as a highly theoretical support of larger types
> than 64 bit in long long. Although that probably will never happen.
> 
> So, if we go with a data type like long long, I would prefer to have
> the code prepared to scale its buffer with the data type, therefore
> BITS(). And let's be honest -- nobody will notice this waste of extra
> 44 bytes.
> 

I'm ok with the diff, except for this detail:

> +u64ton(uint64_t n, char prefix)
>  {
>       char *p;
> -     static char buf [20];
> +     static char buf [BITS(uint64_t) + 2];
>  
>       p = &buf[sizeof(buf)];
>       *--p = '\0';
>       do {
> -             *--p = "0123456789ABCDEF"[n%base];
> -             n /= base;
> +             *--p = "0123456789ABCDEF"[n % 10];

I think you should drop ABCDEF in the string literal here.

Reply via email to