[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