[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOdnd_e7K9Ayn+4pMgWzbu7W8U5dWiSVa9AEKs99m+q7K+g@mail.gmail.com>
Date: Wed, 25 Aug 2021 12:43:53 -0700
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org,
Miguel Ojeda <ojeda@...nel.org>,
Daniel Micay <danielmicay@...il.com>,
Francis Laniel <laniel_francis@...vacyrequired.com>,
Bart Van Assche <bvanassche@....org>,
David Gow <davidgow@...gle.com>, linux-mm@...ck.org,
clang-built-linux@...glegroups.com, linux-hardening@...r.kernel.org
Subject: Re: [PATCH for-next 13/25] compiler_types.h: Remove __compiletime_object_size()
On Sun, Aug 22, 2021 at 11:43 PM Rasmus Villemoes
<linux@...musvillemoes.dk> wrote:
>
> On 22/08/2021 09.51, Kees Cook wrote:
>
> > - int sz = __compiletime_object_size(addr);
> > + int sz = __builtin_object_size(addr, 0);
>
> Not directly related to this patch, but seeing this I wonder if there
> would be some value in introducing names for those magic 0/1/2/3 that
> are used with __b_o_s. Every time I stumble on code using that I have to
> go to the gcc docs, and even then it takes me a while to grok what
>
> TYPE is an integer constant from 0 to 3. If the least significant
> bit is clear, objects are whole variables, if it is set, a closest
> surrounding subobject is considered the object a pointer points to.
> The second bit determines if maximum or minimum of remaining bytes
> is computed.
>
> means. The names don't need to be too verbose, just having a few
> #defines in-tree with the above quoted above them makes it a lot easier
> to figure out what they mean.
We share a similar experience.
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists