[Toybox] tsort

[Rob Landley]

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.

> 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.

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? 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