From owner-svn-src-head@freebsd.org Mon Jan 8 20:08:15 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6B75E5E12A for ; Mon, 8 Jan 2018 20:08:15 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from sonic302-36.consmr.mail.gq1.yahoo.com (sonic302-36.consmr.mail.gq1.yahoo.com [98.137.68.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C151C7136C for ; Mon, 8 Jan 2018 20:08:15 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1515442088; bh=mUMIJf2mzkP+cCeDslERQ+/yADweFxTy/aJRum1lRbM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=Tk4mpd8WhyhH4HiOp9YpAQk51OeoVyZmIGg5iWcBaa1fC9O2pMlRkvYmtWEw1Y871hSUmJwgbqYHfEy+VKd219xkZWnskDX9xHhTWFXjfm+yCBNDqeQTg8J4yVe0G/pQ769lQSnLGhyo9tw4LPAU4vNRrP1b6luL/B4FBRcW0D7zBD18VKgVQ5zUKRBV8V9tIqrxwPc9sn/7dhZLvDdeO4DJNDAWsVzrumpPDi+1re5UvqhYPZd4IIWRmok63WPeKWw/dL85VllfE2JgC+u+oGLJVvXqdGZGgtKMiG05urpoT6eT8gttOYnpN0jFrWk7s0BX3/t60Q4/WRav3327KQ== X-YMail-OSG: pPdtcRkVM1ms67vhmjHuuRBCOnLToajNqaerhKu6JvOl4ZquSbttYP.cf_nUMwc 55r2P5AOSdO3B0K3UH02_lGZ5zm3uy5z4NkESlgWujX27XrYxYqmgFjmWHAkDZNVZ8xHz9qBbmxY yC0AS9jQXIkfxiCWVoGYd5TRqj6lw1v6djJmEwTgMB39U2hufvX0c.QQggJL0yDwKDE_mdnkd1OB NqywQnGr4MHW8OGPUX8I.xUeEf.0j7BVBCzYRRJ1xWufK8cjHUyz7POlrbIgfE6jB3LvO8RzBC0Z ElWOq4wP5QeZaSJxoU84rs_D.UyCNHy_8oNUpeEkGaZiagKUu2EFGSX5HsIo6p7jSZBeHlgvHmIM 9lRM0V5V4TYNoVAxFeXbjza_ueSoOWMvGz5FGyco9.MpvyCzwWTo4Rgny0PagdOJkWZzlXeKzIDC NEBcgyt0EAV25kTYoyVrprQNOAk3naZfoKRJXVTdWIvpta6MHDk8bBQo_ZJw46frGJxeCwIGg Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Mon, 8 Jan 2018 20:08:08 +0000 Received: from smtp102.rhel.mail.gq1.yahoo.com (EHLO [192.168.0.6]) ([216.39.57.211]) by smtp410.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID c1b5a2f9f5d40448375d855a6ae635ce; Mon, 08 Jan 2018 20:08:04 +0000 (UTC) Subject: Re: svn commit: r327697 - head/sys/sys To: Conrad Meyer Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201801081541.w08Ffmm0052729@repo.freebsd.org> From: Pedro Giffuni Organization: FreeBSD Project Message-ID: <1665ddb4-64ad-5d01-902e-2a77a8f5b50c@FreeBSD.org> Date: Mon, 8 Jan 2018 15:08:04 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 20:08:16 -0000 Hi; On 08/01/2018 13:08, Conrad Meyer wrote: > Hi, > > Response inline. > > On Mon, Jan 8, 2018 at 7:41 AM, Pedro F. Giffuni wrote: >> Author: pfg >> Date: Mon Jan 8 15:41:48 2018 >> New Revision: 327697 >> URL: https://svnweb.freebsd.org/changeset/base/327697 >> >> Log: >> malloc(9): drop the __result_use_check attribute for the kernel allocator. >> >> The __result_use_check attribute was brought to the kernel malloc in >> r281203 for consistency with the userland malloc. >> >> For the case of the M_WAITOK flag, the kernel malloc(), realloc(), and >> reallocf() cannot return NULL so in that case the __result_use_check >> attribute makes no sense. >> >> We don't have any way of conditionalizing such attributes so just drop it. > Could we conditionalize the attribute using two different names and a > macro that inspected the (typically) constant flags argument? > Something like this: > > #define malloc(s, t, f) \ > (__builtin_constant_p(f) && (f & M_WAITOK) != 0) ? > _malloc_waitok(s, t, f) : _malloc(s, t, f) > void *_malloc(...) __malloc_like __alloc_size(1); > void *_malloc_waitok(...) __malloc_like __result_use_check __alloc_size(1); > > The two names would just be aliases, or one could invoke the other as > an inline function. That would work but I completely misunderstood the GCC attribute. Quoting the GCC documentation: ____ warn_unused_result The warn_unused_result attribute causes a warning to be emitted if a caller of the function with this attribute does not use its return value. This is useful for functions where not checking the result is either a security problem or always a bug, such as realloc. ____ Retrospectively, our attribute is badly named but it was very difficult to come up with a good name. Pedro.