Re: [PATCH 01/11] Fix base64 module to work with grub codebase

[Robbie Harwood <rharwood@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3166 bytes --]

Simon Josefsson <simon@josefsson.org> writes:

> Robbie Harwood <rharwood@redhat.com> writes:
>
>> The gnulib module makes use of booleans via the <stdbool.h> header. As
>> GRUB does not provide any POSIX wrapper header for this, but instead
>> implements support for bool in <sys/types.h>, we need to patch
>> base64.h to not use <stdbool.h> anymore. We unfortunately cannot include
>> <sys/types.h> instead, as it would then use gnulib's internal header
>> while compiling the gnulib object but our own <sys/types.h> when
>> including it in a GRUB module. Because of this, the patch replaces the
>> include with a direct typedef.
>
> Thanks for trying to upstream diverged gnulib code!
>
> I think this patch is wrong -- gnulib includes a stdbool.h replacement
> you can you use, and the base64 module depends on the stdbool module
> already.  Is there a problem with the stdbool module?  If so, let's fix
> that.

This is helpful feedback, thank you.  I don't know why Patrick chose to
not use that instead, but a local test seems to work.

>> A second fix is required to make available _GL_ATTRIBUTE_CONST, which
>> is provided by the configure script. As base64.h does not include
>> <config.h>, it is thus not available and results in a compile error.
>> This is fixed by adding an include of <config-util.h>.
>
> I think I agree that this is a problem, but your solutions seems wrong.
> There are plenty of header files in gnulib that relies on definitions in
> config.h created by the m4 macro that came with the hader file, yet the
> header file do not #include config.h as usually that is supposed to be
> done by the .c file that include the (say) base64.h header file.  I'm
> not sure assumption is documented anywhere, and if so we should document
> it.  I think this is how it is supposed to work, but if it isn't, we
> should try to come up with a solution for it and document that.

I probably would have been better served by editing the patch
description a bit more here from the original.  To start over from
having poked at it more:

grub2 shims out config.h for some build targets (e.g., when not building
utilities).  So the bits that gnulib's configuration have created end up
in config-util.h - which only sometimes is what config.h is.  Base64 is
used in the luks2 code, which is not always a utility.  It would be nice
to have the files gnulib gives us be "complete" and not need to know
things about the compiler, but honestly this seems a bit like a problem
of grub2's making.

So I think our way forward is to move where we nerf _GL_ATTRIBUTE_CONST
in grub2.  I've tested that this works and will submit to grub2.

Longer-term, this problem could be avoided by dropping the const
attribute from isbase64().  Since uchar_in_range is a macro, b64 is
const, and to_uchar() doesn't do anything, the compiler should be able
to infer this anyway.  (Adding an inline marker to to_uchar() might help
with this.)  What do you think?

grub2 proposed change:
https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00208.html
Assuming grub2 accepts this in some form, I think we can consider this
patch dropped from the series.

Be well,
--Robbie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]