Stop tagging me in your submissions. I have no involvement in any of this activity. -- Andrew J. Hesford a...@sideband.org [Mobile communication]
> On Jul 18, 2024, at 5:25 PM, Alejandro Colomar <a...@kernel.org> wrote: > > On Thu, Jul 18, 2024 at 11:09:40PM GMT, Bruno Haible wrote: >> Hi Alejandro, > > Hi Bruno, > >>> strtol(3) has a limited set of possible states: >>> ... >>> The condition '*endp != s && errno != 0 && errno != ERANGE' is >>> unreachable. The only errno possible if '*endp != s' is ERANGE. >> >> Such a statement can be true if you look at the standards (ISO C, POSIX). >> >> However, there's a difference between what the standards say and what the >> systems actually do. The Gnulib documentation contains thousands of examples >> of such differences. >> >> Gnulib therefore (almost) never assumes that there are no possible errno >> values besides the ones listed in the standards. >> - Some systems return "wrong" errno values. Example: [1] >> - Some systems fail with ENOMEM when memory is tight. Who says that >> an implementation of strtol() cannot use malloc() ? Some implementations >> of strtod() do use malloc(). >> >> So, what you call "dead code", I call "defensive programming". I would not >> like to apply this patch. > > Makes sense. I think we should document that possibility in the manual > page. Maybe say that other errno values are possible in some systems? > Otherwise, it's already a hell of a function to take care of, and most > uses don't handle that possibility at the moment. (Yet more reasons to > use a wrapper that returns -1 & sets errno on error, as the rest of > libc.) > > Would you send a patch? (I'd write it myself, but you probably can > provide more info in the commit message.) > > Have a lovely night! > Alex > >> >> Bruno >> >> [1] https://www.gnu.org/software/gnulib/manual/html_node/getlogin_005fr.html >> >> >> > > -- > <https://www.alejandro-colomar.es/> > <signature.asc>
