(In reply to Kees Cook from comment #14)
> So I'd like to bring this back up and reiterate the issue: there is no
> benefit to the early truncation, and it actively breaks lots of existing
> software (which is why Debian and Ubuntu have had this fix for 10 years now).
>
> What is the _benefit_ of early truncation that justifies breaking so many
> existing cases?
ideally sprintf, snprintf and sprintf_chk would be able to share code and have identical behaviour (currently there is a lot of duplicated logic in glibc with a potential for inconsistent behaviour).
that said, i think _FORTIFY_SOURCE should detect undefined behaviour if possible since it's a bug that breaks portability.
note that it does not matter what guarantees a library documents: there are plenty of precedents for compiler optimizations to break code based on ub in library calls, a compiler can remove all code paths leading to a sprintf(s, "%s", s), trying to make such code work in glibc is just hiding a ticking time bomb.
(In reply to Kees Cook from comment #14)
> So I'd like to bring this back up and reiterate the issue: there is no
> benefit to the early truncation, and it actively breaks lots of existing
> software (which is why Debian and Ubuntu have had this fix for 10 years now).
>
> What is the _benefit_ of early truncation that justifies breaking so many
> existing cases?
ideally sprintf, snprintf and sprintf_chk would be able to share code and have identical behaviour (currently there is a lot of duplicated logic in glibc with a potential for inconsistent behaviour).
that said, i think _FORTIFY_SOURCE should detect undefined behaviour if possible since it's a bug that breaks portability.
note that it does not matter what guarantees a library documents: there are plenty of precedents for compiler optimizations to break code based on ub in library calls, a compiler can remove all code paths leading to a sprintf(s, "%s", s), trying to make such code work in glibc is just hiding a ticking time bomb.