grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Drop gnulib fix-base64.patch


From: Daniel Kiper
Subject: Re: [PATCH] Drop gnulib fix-base64.patch
Date: Tue, 23 Nov 2021 18:20:38 +0100
User-agent: NeoMutt/20170113 (1.7.2)

CC-ing Daren, Patrick and Vladimir...

On Tue, Nov 23, 2021 at 11:08:55AM -0500, Robbie Harwood wrote:
> Daniel Axtens <dja@axtens.net> writes:
>
> > Robbie Harwood <rharwood@redhat.com> writes:
> >
> >> +/* For gnulib's base64 code. */
> >> +#define _GL_ATTRIBUTE_CONST /* empty */
> >
> > Do we support any compiler so old or configuration so weird that we
> > can't simply use 'const' here?
>
> Unfortunately it's not quite that simple.  _GL_ATTRIBUTE_CONST actually
> gates turning on `__attribute ((__const__))`, which if memory serves is
> a GCC extension.  I don't know what the support matrix on grub is, but
> based on the original patch there was a need to support non-gcc-likes.
> Would be fine with changing that, though.
>
> (Personally, I think it should be obvious to a reasonable compiler that
> isbase64() is purely arithmetic.  However, gnulib upstream did not like
> my proposal to drop the attribute marker, so we're stuck with it.)

When I started looking at this issue I realized we have bigger problem
here than lack of _GL_ATTRIBUTE_CONST definition. In general all _GL_*
constants land in config-util.h.in and finally in config-util.h. It does
not make a lot of sense because config-util.h is not included when you
build GRUB core. Instead it is included when you build GRUB utils. Huh!
AFAICT this means the gnulib is deprived of all its specific constants.
I am not sure how it worked at all in so far. Anyway, I think we have
to fix it properly.

Robbie, may I ask you to talk to gnulib folks and ask them how we should
solve this problem? Please CC all folks CC-ed in this email.

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]