Paul Eggert wrote: > > +#if defined __FILC__ > > + if (lenbuf > INT_MAX) > > + lenbuf = INT_MAX; > > +#endif > > ... Should Fil-C be listed as > buggy in doc/posix-functions/snprintf.texi, > doc/posix-functions/vsnprintf.texi, next to other platforms that > mishandle the sizes INT_MAX + 1u (Solaris, z/OS) or INT_MAX + 2u > (FreeBSD, OpenBSD, NetBSD, macOS)?
Yes. When lenbuf has the value INT_MAX + 1, the vasnprintf call fails; when it has the value INT_MAX, the vasnprintf call succeeds. Similarly in lib/unistdio/u-vsprintf.h: The value that I put there is minimal as well. I tested it. > This reminds me of the vasnprintf fix I installed a few weeks ago[1], so > that vasnprintf works with a size equal to INT_MAX + 1u. Perhaps a > similar patch here would provide a bit more functionality on Fil-C? No, this would not work. Also, the comment "that is the maximum the API allows" would be wrong, as the *zprintf API allows return value lengths up to PTRDIFF_MAX, not INT_MAX. > Something like the attacheded untest patch, perhaps, which I stole from > lib/vasnprintf.c? No, none of the three parts would work. Bruno
