[Toybox] tsort

[enh]

On Thu, Oct 12, 2023 at 12:57 AM Rob Landley <rob at landley.net> wrote:
>
> On 10/11/23 11:07, enh wrote:
> >> It's not HARD, I just consider the compiler's behavior to be obviously wrong
> >> here. My code never performs an illegal dereference. I don't see why the
> >> compiler should care what pointer values I'm passing around when they're not
> >> being dereferenced: in C, tracking that is MY job. Their warning generator cares
> >> about things it shouldn't, and there's no override the way you can put
> >> parentheses around an assignment to tell if() or for(;;) that yes, you really
> >> meant to do that.
> >
> > (if you're going to keep getting worked up about stuff like this, you
> > you probably need to join WG14 and argue about it with them.
>
> I'm still on the coreutils mailing list because they haven't merged cut -DF yet.
> I'm still on the busybox mailing list, which went
> http://lists.busybox.net/pipermail/busybox/2023-August/090430.html and I haven't
> followed up. I'm still subscribed to linux-kernel, and haven't pushed my patch
> set there in a while. I'm still on the posix mailing list, and I _think_ I've
> dialed into one of their meetings in the past 12 months?
>
> My toybox todo list gets longer each year. I haven't gotten mkroot even close to
> where aboriginal was when I ended that project. Android is not yet self-hosting.

oh, yeah, don't get me wrong --- i'm part of the problem too, because
i already have too many plates to juggle to be adding another one. i'm
just saying WG14 would be a more productive outlet if you can convert
your annoyance energy into other kinds of energy :-)

> > otherwise
> > only the compiler writers have a voice, and they always vote for
> > whatever lets them implement dodgy optimizations.)
>
> Because I can't rely on LP64 or implement "mount" if it's not approved by the
> posix committee?
>
> One dysfunctional bureaucracy leaving large holes in their spec doesn't mean
> they can't be filled by other standards. It's quite obvious what writing that in
> C _means_, and thus what the behavior should be. The people who refused to admit
> "char is a byte" for over 20 years have never been the final word on how
> compilers actually work. The people who write compilers are also free NOT to
> break obvious code with "optimizations" that don't.

yeah, but that's never going to happen. people like you and me aren't
working on compilers: people who're paid to abuse
unspecified/undefined behavior to get small improvements are.

> You know how keeping data in registers rather than writing it back to the stack
> or heap after each operation was a huge optimization way back when, but code
> that ALSO accessed those values through pointers to the memory didn't get
> penalized with strange magic rules of "sometimes, dereferencing the pointer will
> give you stale data", but instead the compiler writers made it actually work
> right because it was obvious what the code should do and an "optimization" that
> changed how the program ran was broken? Yeah, those were the days...
>
> I didn't try to defend the Linux Standard Base or lanana when the Linux
> Foundation consumed and destroyed the Free Standards Group, because there are
> other standards, and the especially stupid stuff like LSB specifying RPM instead
> of dpkg was widely ignored. Pointing at man7.org was good for a while, now
> Michael Kerrisk's retired and handed off to somebody who hasn't even posted his
> output to the web, but the OLD output has been removed from kernel.org which
> means if you go to man7.org and click "the man pages project" you get
> http://www.kernel.org/doc/man-pages/ which does not link back to man7.org so you
> just have to magically KNOW where the old pages are because you can't FIND them
> anymore, because Konstantin broke stuff. I poked him about it on mastodon, which
> he ignored.
>
> I've pondered building a version of the man-pages git I can post to landley.net,
> but... eh?

i would consider carefully the bandwidth implications of being the
only up to date copy of the man pages on the web :-)

in the meantime, arch linux is doing a decent job, and has much better
formatting than man7.org ever did. most notably, letting you link to
individual sections. if i didn't feel weird about linux to some random
distro's man pages, i'd have s///ed all the bionic header links to
man7.org over already! but i'm not trying to DoS anyone who isn't
explicitly claiming to be "the web's copy of the man pages"!

being able to https://man.archlinux.org/man/fcntl.2.en#File_descriptor_flags
directly is amazing though.

> When I lost access to https://kernel.org/doc I stopped updating
> https://landley.net/kdocs because I had other things to do, and I still have
> other things to do, but... is my website the place for that? Why would
> landley.net be the right place for the web version of the man-pages project? I
> haven't bothered to update https://landley.net/kdocs/fullhist/ so your resulting
> "git pull" isn't enormous (3.0->6.6 is big) because that's really not the
> appropriate place for that to live, but nobody upstream in kernel-land has
> wanted to support that. I still haven't worked out how to run the Linux 0.0.1
> images from https://lwn.net/Articles/263562/ on a modern QEMU version, I should
> really engage with the QEMU people to try to fix that, and mirror the binaries
> somewhere other than pulling them from archive.org off a years-dead site where
> the new domain owner COULD put up a robots.txt which blocks the history because
> archive.org honors those retroactively (sigh), but... I'm busy.
>
> >> If Elliott really really wants the blah[3], keep=blah+1 version I can do that.
> >> But the compiler would still be wrong, and I don't volunteer danegeld. (The
> >> compiler keeps threatening me with a good time. "Warning: yes, I want that to
> >> happen.")
> >
> > given that (as you quoted above) i haven't seen anyone use tsort since
> > i last had to suffer AIX's linker ("the worst linker ever written") in
> > the 1990s, i haven't enabled tsort and have no plans to do so.
>
> Eh, maybe it's cleaner to do it anyway. I was just annoyed.
>
> Rob