From owner-freebsd-pkg@FreeBSD.ORG Fri Nov 29 21:40:28 2013 Return-Path: Delivered-To: freebsd-pkg@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F2E4C9D for ; Fri, 29 Nov 2013 21:40:28 +0000 (UTC) Received: from kaworu.ch (kaworu.ch [IPv6:2001:41d0:1:5db0::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1792610EC for ; Fri, 29 Nov 2013 21:40:26 +0000 (UTC) Received: from [192.168.0.18] (46-126-186-69.dynamic.hispeed.ch [46.126.186.69]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex@kaworu.ch) by kaworu.ch (Postfix) with ESMTPSA id 98C6C89422 for ; Fri, 29 Nov 2013 22:38:34 +0100 (CET) Message-ID: <529909B9.2050007@kaworu.ch> Date: Fri, 29 Nov 2013 22:40:09 +0100 From: Alex User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-pkg@freebsd.org Subject: [dev] about unchecked functions calls X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-pkg@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Binary package management and package tools discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 21:40:28 -0000 Hi list, We do have currently several libc function calls that are completely unchecked. Amongst them, the malloc(3) family calls are almost always assumed to succeed and I am feeling uneasy about it. To be honest, I've never experienced genuine ENOMEM as a programmer. What makes me uneasy is that I personally think that when writting C, one has to take a stand on some question like "what do I do if malloc(3) ever fail?". UNIX as a strong tradition about robust C programming and we should embrace it. 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.). 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. To me, (1) is better that what we do now (i.e. nothing) and (2) is better than (1). Obviously, (1) can be achieved easily while (2) is a long process. I've been playing Coccinelle[1] on the pkg codebase recently (long story short: Coccinelle is a matching and transformation engine for C). What is relevant to know is that Coccinelle is a great tool to achieve (1), and that I am willing to integrate it. In other words we have a way to step quickly to (1). My proposition is to use Coccinelle in order to step to a first goal (1) and achieve (2) as a second, long-term and shared goal. If at anytime (2) seems unreasonable, we can still drop it and fallback to (1). It is much more a change of mindset than a change in the code. It's about writting cleaner, hopefully more robust code. I think that the two steps could (and should) also be applied for other other calls like strlcpy(3). However, in order to succeed cooperation is required at every levels (all the contributors should try to comply to it and commiters should enforce it). Therefore comments and inputs are welcome, in particular from current active pkg commiters. Regards, Alex. [1]: http://coccinelle.lip6.fr/