On Mon, Dec 3, 2018 at 12:09 PM enh <[email protected]> wrote: > > On Mon, Dec 3, 2018 at 11:33 AM Rob Landley <[email protected]> wrote: > > > > On 12/3/18 12:00 PM, enh wrote: > > > amusingly, the same line causes a (different) compile-time warning > > > with old versions of glibc. glibc 2.15 at least has mktemp marked as > > > warn_unused_result, and AOSP currently uses glibc 2.15 for host > > > builds. i've sent a patch to fix that (and attached the same patch > > > here too, in case the spam filter is still messing with you :-) ). > > > > I enabled the header rewrite whatsis in the list plumbing and that seems to > > have > > fixed the worst of it. > > > > I was looking at doing my own mktemp with xgetrandom() but the x part says > > "denial of service attack/exploit waiting to happen" when a script calls > > NAME=$(mktemp) and gets an empty string with some discarded stderr output... > > > > If bionic and musl _both_ don't warn about it, it's a glibc bug. Still > > annoying, > > but I'll leave it for now and check if I still feel like trying to do > > something > > about it during pre-release cleanup... > > well: > > * POSIX 1003.1-2008 removed mktemp(3). > > * musl has no compile-time deprecation/warn_unused_result warnings for > anything. > > * bionic _does_ have a compile-time deprecation warning for mktemp > because _most_ callers shouldn't use it (and POSIX did remove it, even > if it seems unlikely that any libc will remove it any time soon). > mktemp(1) -u/--dry-run just happens to be a weird exception where two > wrongs make a right. > > * glibc doesn't have a compile-time deprecation warning because it's > guarded behind "are we pre-2008 POSIX?". > > * glibc does have a link-time deprecation warning. > > * old glibc did have a compile-time warn_unused_result warning, but > apparently they've thought better of that since and removed the > attribute. > > so it's all just a big mess, really :-) > > (and, yes, i have seen uses that can't actually write to the directory > --- the basic [anti-]pattern seems to be "there's something exposed > via something like /proc, i want a unique name in that namespace, but > there's some other mechanism for creating the thing than mkdir(2)". as > far as i can tell, these are tests rather than production code.)
this made me realize i should have a test for this, and writing the test uncovered cases where the mktemp logic still wasn't right. i've sent a new patch with the missing tests and a rewrite of the logic that chooses between DIR, $TMPDIR, and /tmp. > > > someone's looking at upgrading the host glibc, but 2.15 is just inside > > > the 7-year rule. plus i assume you'll be happy to save a line anyway. > > > i'm not sure why i didn't write it as one line in the first place... > > > even i don't find it obfuscatory in this case. > > > > Applied. > > thanks. > > > Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
