9front - general discussion about 9front
 help / color / mirror / Atom feed
From: covertusername967@gmail.com
To: 9front@9front.org, covertusername967@gmail.com
Subject: [9front] libmp and error handling
Date: Tue, 20 Oct 2020 22:56:04 -0500	[thread overview]
Message-ID: <D61860A06A3D437F1980A9EDAC27510F@gmail.com> (raw)

Hello,

I was working with libmp today trying to figure out error handling.
mp(2) says the following:

          Routines that return an mpint will allocate the mpint if the
          result parameter is nil.  This includes strtomp, itomp,
          uitomp, btomp, and dtomp. These functions, in addition to
          mpnew and mpcopy, will return nil if the allocation fails.

However, reading the source code reveals something entirely different:
while the routines do allocate a new mpint if needed, if allocation
fails they don't return nil and instead outright call sysfatal.  I
then checked the rest of the code in the system that uses libmp and
all of it relies on the undocumented behaviour, assuming that returned
pointers are valid.

There's both an easy way and a hard way to fix this.  The easy way
would be to document the sysfatal call in the manpage and mention that
sysfatal should be overridden in order to change the error handling.
The hard way would be to remove the sysfatal calls in libmp, then
change the rest of the system so that it catches the errors.

The hard way looks like it would be more correct, but could also break
compatibility with other software.  I don't know who uses libmp other
than the rest of userland, however, so I would like to ask if there
are any other users at all, and if so, if you object to changing
libmp.  I have a need for this and can put a patch together if this
change seems okay.



             reply	other threads:[~2020-10-21  3:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-21  3:56 covertusername967 [this message]
2020-10-21  4:08 ` Alex Musolino
2020-10-21  4:27   ` covertusername967
2020-10-21 13:53     ` ori
2020-10-24 23:52       ` covertusername967
2020-10-25  0:25         ` ori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D61860A06A3D437F1980A9EDAC27510F@gmail.com \
    --to=covertusername967@gmail.com \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).