Created attachment 399294 [details, diff] fix compilation against musl sys-libs/efivar fails with an error related to the usage of `__va_arg_pack_len`. additionally, a strange assumption about sizeof(char) causes a runtime segfault. Attached is a patch that fixes the issue, make against the hardened-dev musl branch.
Just curious: Where did sizeof (struct guidname) come from?
it allocates memory for a guidname struct using sizeof(char) instead of sizeof(struct guidname) and the comment explains this away by saying "strictly speaking, this *has* to be too large.". actually, i'm not sure if the comment is explaining this away, or asking why it's written like that. i'm somewhat confused myself. the other part of the patch, for `__va_arg_pack_len`, seems to just be a consistency issue as the builtin version is used just a few lines above.
(In reply to Travis Tilley from comment #2) Ah I see what's happening there. Since sizeof(char) is the 1 on just about any sane system, it is effectively calling calloc(inlen, 1). It is allocating a buffer of the same size as the input file. The for loop below it expects at least enough space to hold one struct guidname for each line in the input file. I wonder why it doesn't just count the number of lines in the input file and use that for the calloc call?
Okay I committed this to the musl overlay. But the patch should go upstream. It looks reasonable. I'm leaving bugs that still need upstreaming as IN_PROGRESS.
Patches sent upstream: https://github.com/rhinstaller/efivar/pull/17
Upstream as of https://github.com/rhinstaller/efivar/commit/066bf288c3ba924cd272fc27f4145871133ff18e
@floppym. Looks like there's been a bunch of releases since 0.15 in the tree. Should we bump? (I'll take care of it to not burden you).
(In reply to Anthony Basile from comment #7) > @floppym. Looks like there's been a bunch of releases since 0.15 in the > tree. Should we bump? (I'll take care of it to not burden you). We are now on the current release (efivar-0.21), so I'm closing this.
(In reply to Mike Gilbert from comment #8) > (In reply to Anthony Basile from comment #7) > > @floppym. Looks like there's been a bunch of releases since 0.15 in the > > tree. Should we bump? (I'll take care of it to not burden you). > > We are now on the current release (efivar-0.21), so I'm closing this. Okay we'll just used the ~arch version. I'm removing the ebuild from the musl overlay.