Date: Sat, 30 Nov 2013 10:02:20 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: freebsd-pkg@freebsd.org Subject: Re: [dev] about unchecked functions calls Message-ID: <5299B7AC.1000603@infracaninophile.co.uk> In-Reply-To: <529909B9.2050007@kaworu.ch> References: <529909B9.2050007@kaworu.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JFja7vFwEsiMqbQnGtVDBPWSbrvq7dmd7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 29/11/2013 21:40, Alex wrote: > About solutions, the alternatives I have in mind are: >=20 > 1. assume that ENOMEM is fatal. We just abort() as soon as we see it. I= n > 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 t= o > 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 ou= t. 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 genera= l > 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 b= y > its name) then maybe this is the Right Thing=99 to do. Basically, it me= ans > that functions considered part of the library would return an error cod= e > (EPKG_FATAL) while other "higher part" would gracefully cleanup and exi= t > (using for example err(3)). On the pros side we would have a more robus= t > application, a more reliable library and a cleaner codebase. On the con= s > 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 --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matthew@infracaninophile.co.uk --JFja7vFwEsiMqbQnGtVDBPWSbrvq7dmd7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJSmbe0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATzP8P/2MIfz0+gGN0wX62dj9zNtWv jkqBCWZ+dpaVqy/6RUHQdTVIe4xaidCaBxDS6dx8fXHFzyIS78D03+XRGZm3s/25 BQTqaMi2WdVjddKdYqyAc1omS+VlnhS8x6lVsXpErStO9sxkFNptrNzM0hOxDNAX +9KVhJDfYRqvmvuQxEmVVsjFr2BwOdDa1h8dsUYV97o/QmzIjnfaw99TA/baDuSG H/04GCuEXvcrtf1ZdMguM6Ji8pDVf++EISM/f63d6+m8al2ATkB7giwYhJk6/9E7 onVg4wKv9buJs0jL1spFzqT2nUBmGONkOmycY1qIHE5UNPSABUZZ6L7jLzNSe5l8 Xk+eqsZetRBLstFvJzTJnMlzGnOayNE0kSJD2IYOvCUeYHpE7rU0FcY+0wEwEp9k g4hISd9ncVwTZMkfpcG3RMvihpLuDDZzIBCKbNt/D7XODt/KvJDmMIT4WpHRY+iX x0RoFnw0aqS63u+zzZ6FPV2hnIONsQvQ6/YOhGxDkTjGk8EwcpYbh4PEKuJKU06F zLrq0oRv6I6fQ5Jjc0WgQDNd35pORpwc4k8J/YzkV2zAfXNz0sIATplsV9TOCdFD 9HhCG2zKP1DSC92mh+31kZNLyFUM/MFDuXwJNV174fjcOR2ftjQmkx54Bruxuarn 322zY73mddNXpT8dy9qm =tvkm -----END PGP SIGNATURE----- --JFja7vFwEsiMqbQnGtVDBPWSbrvq7dmd7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5299B7AC.1000603>