__libc_fatal public version?

[Cristian Rodriguez]

On Wed, Dec 31, 2025 at 9:29 AM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 30/12/25 11:07, Cristian Rodríguez wrote:
> > Hi:
> >
> > Many, many low level software requires exactly what __libc_fatal does,
> > a way to fail catastrophically with a message in any context.. (well
> > in almost any context as long mmap is able to get some virtual memory)
> > All the other ways are not as-safe, applications cannot count on them
> > been usable in signal handlers for example
> >
> > Would it be possible that you will consider either :
> >
> > - export this to userspace or
> > - extend the "error" api, something like error_ss , warn_ss or if all
> > that is too much
> > - implement the equivalent to the netbsd libc functions snprintf_ss,
> > vsnprintf_ss
> >   and leave the implementation of the rest of the code to applications
> > providing an example use im the documentation?
> >
> > Thanks for reading..
>

> There is also the question of whether we want atomicity in the kernel interface,
> both in the loader and in __libc_message_impl, by using writev with a static
> iov struct. This limits the maximum number of arguments in the format string.

Yes, this is another characteristic of the interface that is
desirable.. having limits on the number and type of arguments seem
reasonable
given the context. most apps I have seen will want a few %s and  %d
%zu and that's pretty much it. many will just output text and  errno
number or %#m