CC-ing Daren, Patrick and Vladimir... On Tue, Nov 23, 2021 at 11:08:55AM -0500, Robbie Harwood wrote: > Daniel Axtens <d...@axtens.net> writes: > > > Robbie Harwood <rharw...@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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
