linux-kernel - Re: Complaint about return code convention in queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 20 Aug 2006 10:27:49 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Alan Stern <stern@...land.harvard.edu>
cc:	Alexey Dobriyan <adobriyan@...il.com>,
	Jeff Garzik <jeff@...zik.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Andrew Morton <akpm@...l.org>, "Theodore Ts'o" <tytso@....edu>
Subject: Re: Complaint about return code convention in queue_work() etc.

>> > >I'd like to lodge a bitter complaint about the return codes used by
>> > >queue_work() and related functions:
>> > >
>> > >	Why do the damn things return 0 for error and 1 for success???
>> > >	Why don't they use negative error codes for failure, like
>> > >	everything else in the kernel?!!
>> >
>> > It's a standard programming idiom:  return false (0) for failure, true
>> > (non-zero) for success.  Boolean.
>> 
>> There are at least 3 idioms:
>> 
>> 1) return 0 on success, -E on fail¹.
>> 2) return 1 on YES, 0 on NO.
>> 3) return valid pointer on OK, NULL on fail.

I wrote something up some time ago,
http://svn.sourceforge.net/viewvc/vitalnix/trunk/src/doc/extra-aee.php?revision=1

>Functions can return values of many different kinds, and one of the most
>common is a value indicating whether the function succeeded or failed.  
>Such a value can be represented as a "status" integer (0 = success, -Exxx
>= failure) or a "succeeded" boolean (1 = success, 0 = failure).
>
>Mixing up these two sorts of representations is a fertile source of
>difficult-to-find bugs.  If the C language included a strong distinction
>between integers and booleans then the compiler would find these mistakes
>for us... but it doesn't.

Recently introduced "bool".



Jan Engelhardt
--