bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: string types


From: Bruno Haible
Subject: Re: string types
Date: Sun, 29 Dec 2019 10:19:07 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-170-generic; KDE/5.18.0; x86_64; ; )

Aga wrote:
>   - the returned value of the *printf family of functions dictates their
>     limits/range, as they return an int, this can be as INT_MAX mostly

Yes, we need new implementations of the *asprintf functions that are not
limited to returning strings of maximum length INT_MAX.

>   - as since there is a "risk"¹ that someone has to take at some point 
> (either the
>     programmer or the underlying library code (as strdup() does)), the 
> designed
>     interface should lower those risks

I agree with the goal. How to do it precisely, is an art however.

> In the case of an error, returns > 0 which is either:
> #define   EDSTPAR   -1                /* Error : bad dst parameters */
> #define   ESRCPAR   -2                /* Error : bad src parameters */
> #define   EMODPAR   -3                /* Error : bad mode parameter */
> #define   ETRUNC    -4                /* Error : not enough space to 
> copy/concatenate
>                                                          and truncation not 
> allowed */

I don't think an interface for string concatenation with that many error
cases will be successful. Programmers are lazy, therefore
  - some will not check the errors at all,
  - some will only check for the fourth one (because "I'm not passing invalid
    arguments, after all"),
  - among those few that implement all 4 checks, half will get it wrong
    (that's my experience with similarly complex functions like mbrtowc() or
    iconv()).

For an interface to be successful, it needs to be simpler than that.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]