Re: [PATCH v2] abort: clarify consequences of calling abort

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

 



Hi,

On Mon, Jul 10, 2023 at 10:21:50AM -0500, G. Branden Robinson wrote:
> Hi Tomáš,
> 
> At 2023-07-10T15:59:28+0200, Tomáš Golembiovský wrote:
> [...]
> > Clarify the status reported by wait*() functions. The requirement
> > comes from POSIX specification.
> [...]
> > +The status made available to
> > +.BR wait "(2), " waitid "(2), or " waitpid (2)
> > +by
> > +.BR abort ()
> > +shall be that of a process terminated by the
> > +.BR SIGABRT
> > +signal.
> [...]
> 
> I believe Alex's preference in the Linux man-pages project is to
> document what is actually implemented, not to repeat normative language
> (paraphrased or not) from the POSIX standard.

Yeah, I don't feel strong about it and I have my doubts if mentioning is
useful anyway. It should be obvious from the fact that abort() raises
SIABGRT. I will drop that sentence. 

> 
> So glibc should be tested to verify the behavior it actually exhibits,
> and the language above then updated to describe that, noting any
> deviation from POSIX's prescription.

As a side note, in the normal situation glibc does what it should.
However, in the unlikely situation that raise() fails unexpectedly,
abort() tries to terminate the process with other means or loops for
ever if everything else fails to satisfy the condition that abort()
should never return.

    Tomas

> 
> The same can, optionally, be done for other libcs like musl.
> 
> Alex, please correct me if I'm mistaken.
> 
> Regards,
> Branden





[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux