[dev] about unchecked functions calls

[Matthew Seaman]

On 29/11/2013 21:40, Alex wrote:
> About solutions, the alternatives I have in mind are:
> 
> 1. assume that ENOMEM is fatal. We just abort() as soon as we see it. In
> that case we should have some kind of xmalloc(3) & Co. and use them
> consistently accross all the project. On the pros side it's very easy to
> do, on the cons it could leave the system in a unclean state (half done
> install / uninstall, corrupted pkg database etc.).

abort(3) is almost certainly the wrong answer.  If malloc(3) et al fail,
then, yes pkg(8) should terminate itself.  But it should rollback any
pending database transactions and perform other cleanup and generally
take care to leave the system in a consistent state.

The other critical condition we have to cope with is running out of
space on the filesystem.  Again the ideal is to leave the system in a
consistent state -- no half installed packages and preferably without
having deleted a package prior to upgrading it, but failing to install
the newer version.  (I don't think we can make an absolute guarrantee
that won't happen in the general case, but we can make pkg(8) resistant
to it (well, we already do), and we could certainly facilitate using
features like filesystem snapshots where those are available.)

Note 'consistent' here means pretty much treating each package
atomically; so we always complete the operation on one package or roll
back to the previous one.  That's not necessarily going to leave the
system in a state with all package dependencies properly fulfilled, but
it will mean its in a state where further pkg(8) calls can sort things out.

This is by no means an academic consideration: we want to support
embedded systems and those may well be quite memory constrained, so
handling all that as gracefully as possible is going to be important.

> 2. assume that pkg should fail gracefully when ENOMEM occurs. In general
> it is considered bad design for a library to abort() (in any case) and
> so if part of pkg can be considered as a library (like libpkg suggest by
> its name) then maybe this is the Right Thing™ to do. Basically, it means
> that functions considered part of the library would return an error code
> (EPKG_FATAL) while other "higher part" would gracefully cleanup and exit
> (using for example err(3)). On the pros side we would have a more robust
> application, a more reliable library and a cleaner codebase. On the cons
> side it is hard to achieve and time consuming.

Yes, indeed.  libpkg functions should either succeed or indicate failure
by returning an error code.  It's up to the calling program to handle
the consequences of the failure.

> steps could (and should) also be applied for other other calls like
> strlcpy(3). However, in order to succeed cooperation is required at

Huh?  What's wrong with strlcpy(3)?  strlcpy is a *good thing* and
should be used in preference to strcpy(3) or strncpy(3).  Which we
generally do already.  Similarly snprintf(3) rather than sprintf(3) and
similarly bounded functions which won't overrun memory buffers.

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matthew at infracaninophile.co.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1036 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-pkg/attachments/20131130/e767fe1f/attachment.sig>