From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751716AbcBKQkH (ORCPT <rfc822;w@1wt.eu>);
	Thu, 11 Feb 2016 11:40:07 -0500
Received: from mout.kundenserver.de ([212.227.126.131]:63525 "EHLO
	mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751238AbcBKQkE (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 11 Feb 2016 11:40:04 -0500
From: Arnd Bergmann <arnd@arndb.de>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        open list <linux-kernel@vger.kernel.org>,
        Bob Peterson <rpeterso@redhat.com>, linux@rasmusvillemoes.dk
Subject: Re: [PATCH v3] err.h: allow IS_ERR_VALUE to handle properly more types
Date: Thu, 11 Feb 2016 17:39:49 +0100
Message-ID: <3104312.nOVEcCskuj@wuerfel>
User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; )
In-Reply-To: <56BC31A6.4060102@samsung.com>
References: <20160202163350.f7d42f4b97f48756f3900e9a@linux-foundation.org> <2469004.dGELCApkKV@wuerfel> <56BC31A6.4060102@samsung.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:e2OenpiP9MWzOpG/UdrScnykcmvUqMOz/+d+S5q7vgb/Tok2ySj
 LoFLmbFuEph8dYE8m4DH0zNyNiJlj/b8IJ9fHpMqSSLMcyTtg7onIyJOVs/Fq074BZA/Fxf
 +qsi3k4aOY1GQRLtvHkHtubirNdbsUvBaV88koyrkpMB0zpSN+EcyupqqwPLgxakEModR1M
 czjNNis+UH6WdunpBPivA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:gYddjoH+qEc=:ww5R5flqPf7Rx5JuhLGqo6
 SYDWzJg2jyQ6qaUHBsLoyi0zlNp3OK8AIaHgCPY/Lo/H0a5+mfhBDGyjQCrqzp7k9E8G1WD95
 0v4kotPRa3/VwEA5BGqUcIziA4kiX8IU2ka+QilEP4QU00qkcbMaZ/opyWxipd6pR+YyM2Lky
 0UKW6Xqpuw/J3ilJ8ZGRSO+xcO52Vq7Jxl6wcHQQ4Frntjte0aBCKwxs70NOBGndkhOUivh5V
 EWeZA+bwDiiygbXmuujt5WJBxuKyYTSCq4ZWlYmXnhDleAb0j5pSNb439tD4y+cSZ7rJscKV9
 vycJFD6ECm7JD+uVcSxZSHATz2I1hi7xQr8/tHmPAyoJOr16048yZdl9NFT8BV2fJdAeWuadN
 qhJCCmXrmd+GpaZT00c4n7tY/5u8ChCpF0/mwOHyd1n1yyPAadmQ0hAWyf+kRYGj6To2SiAAV
 rENcgq5NoLMhj4e0ds/yaTjQYAd28LCq0UXr12Y8OpeG/Qzqi2r8RYyuGG+78VopsvsRUd/LS
 V6c64GCxWGdixGMm2yoK2njcP37ttvWHsXO9uxx8ckf0T5tRStAJYpVGB8rjKVLShTOzsl0vr
 RzCYSMUNUIY1jOu41ilLFc+Q7ko5IBOjI/qIwKXnLpy3D2YX9hajQtxGG2FoDtz2FkW8dHpUC
 E+yHC/iF+0BVQm+YMqxcRWyU7ZGpUcgCI72Zde+XgvfL+z2dGDZj8KFNSXmR1dXfYuvRu5zL/
 HvBzapV6xwAHd/9j
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thursday 11 February 2016 08:00:54 Andrzej Hajda wrote:
> > I think the easiest way to express this would be to ensure that the argument
> > is 'unsigned long', like:
> >
> > #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
> >        unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
> 
> This way you will limit it only to unsigned long type, which seems too
> strict to me.
> I think the macro should accept all long enough unsigned types, otherwise we
> could end up with bunch of macros IS_ERR_VALUE_U32, IS_ERR_VALUE_ULL...

I think in practice we only care about 'int' and 'unsigned long', which are
the ones that 90% of the existing users pass in today. u32 has never worked
on 64-bit architectures so far, so we don't necessarily have to make it work.
As Al mentioned, most users of IS_ERR_VALUE are wrong anyway and should
just use 'if (err < 0)' or 'if (err)'.

We could also consider making just 'int' and 'unsigned long' allowed types
for the moment, and then change all users passing 'int' before forbidding them.

	Arnd