From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f41.google.com ([209.85.210.41]) by ewsd; Tue Oct 20 23:56:11 -0400 2020 Received: by mail-ot1-f41.google.com with SMTP id i12so664281ota.5 for <9front@9front.org>; Tue, 20 Oct 2020 20:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:to:subject:date:mime-version :content-transfer-encoding; bh=bAZv+vZ9YSiWZtd+S38mp414LsAfaIvOPiAmdl5WWfM=; b=psgO0/MoQYhiKP5GGOvzrzB1LyJswfpBJGAzLAnfLUbQffEeYnVotHl4msJ8Ufefvc sSKzMSoZxnTxZzGtN83IfU/kud9QJiz+T0Fqci3S1uLgRf9uvj42N3Fkmo5X4ISrpKAD 9E28I6TAfNcZLtOJ3UaqjggCRWEdrzsy+eqIRdqDAfFxsSGkORCegA1VnVxI/C4OqCW/ lK/bV/rfaVzJuXkLGQDAvoy1MviatyGHGJnr0rxZNXIPbA+rkdcpg8QW8Untrf2KxfsK En9BfzPWNWyi1eYZ8gFghAYdJ2m7wTJFMR09ITN5nCR+2qAK1MkJEnijcm4OqFduYrIj wBbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:to:subject:date:mime-version :content-transfer-encoding; bh=bAZv+vZ9YSiWZtd+S38mp414LsAfaIvOPiAmdl5WWfM=; b=Tu10AtE0v/2yfhcx1upSp3DFIhu8QMOboTRIm56nAj6w6ONMdmGytMSgN2udEjrZ8B daiRuLGJG+IeLz06me1Csyjp4Xk6SICOjC6CwuzDeu/2RCysYFKBuRhGAva2qqVlPNny dQlHCUkc5FkZC+EVShmju6YOsVBirwrsS0n9EyInVO4G7bRqH/roVDwbm8DrhyLtZkDK zi6+YQ6KJVUl6m6we5AUpMpxIaNsTtfvWkF9hcRKBhjgq//3hOL6UP2LOW2Gdzs7rgRj NCQPGAgf1Uf9Q9VbGfR9NYjmo3SFDA35tzbCgmiADN4cUy7TeYLpXkHtLEwb6RG7Zj8w g9kQ== X-Gm-Message-State: AOAM532+XyRCQhlsBBmDs8lz+wUb5Q0tY4MC9xC4r1xg7D1wE6ZYq0MD ZBx8ho0WI+JrsJf8nUiIfN4y5H0nCc9y9w== X-Google-Smtp-Source: ABdhPJyen6Bzduu9cen5UMEuRm7Zk8keaT2rm2AAwIG5QHxWMPn5m0KrlSxe5rjdxEMWgPDqeJ4F6Q== X-Received: by 2002:a9d:6acc:: with SMTP id m12mr1026571otq.95.1603252566106; Tue, 20 Oct 2020 20:56:06 -0700 (PDT) Return-Path: Received: from dell9term.covert9net (67-198-106-217.dyn.grandenetworks.net. [67.198.106.217]) by smtp.gmail.com with ESMTPSA id z25sm273353ood.21.2020.10.20.20.56.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Oct 2020 20:56:05 -0700 (PDT) From: covertusername967@gmail.com X-Google-Original-From: glenda@gmail.com Message-ID: To: 9front@9front.org, covertusername967@gmail.com Subject: [9front] libmp and error handling Date: Tue, 20 Oct 2020 22:56:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: stateless encrypted YAML over AJAX base hypervisor 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.