[ccan] [PATCH v2 2/2] maskn & bitops: add new modules

[Cody P Schafer]

On Mon, Jul 14, 2014 at 7:06 PM, David Gibson
<david at gibson.dropbear.id.au> wrote:
> On Mon, Jul 14, 2014 at 04:34:46PM -0400, Cody P Schafer wrote:
>> On Sat, Jul 12, 2014 at 4:10 AM, David Gibson
>> <david at gibson.dropbear.id.au> wrote:
>> > On Thu, Jul 10, 2014 at 08:29:32PM -0400, Cody P Schafer wrote:
>> >> On Thu, Jul 10, 2014 at 7:08 AM, David Gibson
>> >> <david at gibson.dropbear.id.au> wrote:
>> >> > On Wed, Jul 09, 2014 at 09:49:44PM -0400, Cody P Schafer wrote:
>> >> >> 'maskn' provides generation of n-bit masks from a given range.
>> >> >> 'bitops' provides some generic bit operations that maskn needs.
>> >> [...]
>> >> >> diff --git a/ccan/bitops/bitops.c b/ccan/bitops/bitops.c
>> >> >> new file mode 100644
>> >> >> index 0000000..a9c233b
>> >> >> --- /dev/null
>> >> >> +++ b/ccan/bitops/bitops.c
>> >> >> @@ -0,0 +1,10 @@
>> >> >> +/* CC0 (Public Domain) - see LICENSE file for details */
>> >> >> +#include <ccan/bitops/bitops.h>
>> >> >> +
>> >> >> +extern inline uintmax_t bit_mask_nz(unsigned bits);
>> >> >> +extern inline uintmax_t bit_mask(unsigned bits);
>> >> >
>> >> > Hrm.. does "extern inline" actually have a well-defined portable
>> >> > meeting?
>> >>
>> >> In c99 and later, yes. The c99 rationale (
>> >> http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf ) has
>> >> some details, which this stack overflow post (
>> >> http://stackoverflow.com/a/6312854 ) has a textual copy of.
>> >>
>> >> c89, on the other hand, lacks inline and gnu89 reverses the meaning of
>> >> "extern inline" and "inline".
>> >>
>> >> > I still think these functions are so simple they should be static
>> >> > inlines, at least the builtin versions.  Not everyone has LTO.
>> >>
>> >> Well, I don't want these to be unconditionally inlined. I'd very much
>> >> rather have the compiler decide than increase code size even when it
>> >> isn't a great idea.
>> >
>> > But won't the builtin versions be an instruction or two?
>>
>> This really depends on the architecture. And the inline+extern inline
>> lets the compiler choose. I don't see a good reason to take that
>> choice away (unless someone wants c89 support?)
>
> Hrm.  Except that in the case they're not, I would have expected the
> compiler to already insert a function call, rather than open-coding it
> at the point where the builtin is used.

Not sure if I replied to this already, but just in case:

Right, if the compiler supports the builtins, it will magically do the
right thing. The problem is when it doesn't know the builtins. The
inline/extern inline pattern was created as a way to (in a sense) add
builtins without modifying the compiler by providing a way for it to
know the internals of a function in every translation unit while still
allowing calls to the function if the compiler deems it optimal.