[Toybox] ftell/fseek

[Rob Landley]

On 2/22/23 18:58, enh wrote:
> On Wed, Feb 22, 2023 at 4:46 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 2/22/23 15:52, enh wrote:
>> > i've sent a patch upstream (with you cc:ed) anyway. (patches still
>> > seem to get in without michael kerrisk --- it's "just" web site
>> > updates that don't happen.
>>
>> Apparently he handed off maintainership:
>>
>>   https://www.spinics.net/lists/linux-man/msg24435.html
>>
>> And indeed, he's listed as comaintainer at:
>>
>>   https://www.kernel.org/doc/man-pages/maintaining.html
>>
>> I dunno what the keys are for updating kernel.org/doc/man-pages. Many moons ago
>> (http://landley.net/hg/kdocs) I used to maintain kernel.org/doc but I lost
>> access after that whole kernel.org breakin and the move to kgit or whatever that
>> nonsense was, since I could no longer rsync https://landley.net/kdocs up to the
>> site.
>>
>> I at least made puppy eyes at konstantin until he hacked up something for
>> https://kernel.org/doc/html/ and https://kernel.org/doc/Documentation/ and so on
>> to update, and hey, he even salvaged the README finder, cool. Although my
>> https://web.archive.org/web/20120121090059/http://www.kernel.org/doc/menuconfig/
>> Horrible Python Script was beyond him and he wound up just removing that...
>>
>> Anyway, back when I _did_ have access I created a man-pages subdirectory that
>> Konstantin chowned so mkerrisk could write to it, but I dunno what he used to
>> update it? Especially after I lost the ability to do so. (They wanted me to do
>> some sort of "check your thing into git and it'll do an automated git checkout",
>> and I was going "you took down Greg KH's 2 gigabyte tutorial video so I was
>> gonna mirror it until it could get better hosting, do you really want that
>> permanently in the git history even after I delete it again?" I blogged quite
>> sarcastically about this at the time...)
>>
>> Ha, the c99 html link is a bit stale there. I mean it's still there, but dude...
>> Oh, the "legacy reasons" link moved, I'll ping konstantin. Huh, several of the
>> links further down are broken now, not sure what to do about the linux-journal
>> archives. The individual articles are still there but the index isn't...
>>
>> > which is pretty debilitating for anyone who
>> > doesn't have a local git clone of man-pages.git, which is "basically
>> > everyone" :-( )
>>
>> The new guy says it moved to:
>>
>>   https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/
> 
> no, the _git_ project is fine. i've made several updates to that in
> the last few years. they're just not making it out to
> https://man7.org/linux/man-pages/man3/fseek.3.html which is where
> people actually end up. (younger people especially seem to ask the
> internet first rather than type `man foo`.)

Sigh, https://www.kernel.org/doc/man-pages/ is all links _back_ to man7.org
isn't it?

Possibly the new maintainer needs to poke Konstantin to get access to update the
directory, and then put stuff under the actual kernel.org page? (Or you could
put some under an android.org location? Either way they'd be up to date with the
repo instead of a couple years behind...)

Let's see, how hard is it to produce html output from this git repo... it's got
a top level Makefile to do exactly that as its default target, but it wants a
package called "man2html". And installing that on my laptop installed apache
which LAUNCHED AN INSTANCE ON LOOPBACK. Why on EARTH would... that's just sad.

But ok, I can uninstall it again after building... looks like it populated
tmp/html with files? No top level index. Let's see, the first file under "man3"
is __after_morecore_hook.3.html which seems to be a synonym for malloc_hook (not
symlinks or hardlinks, just redundantly generated files). The "Return to main
contents" link goes to file:///cgi-bin/man/man2html which does not exist. The
#include <malloc.h> link goes to file:///usr/include/malloc.h which ain't gonna
work on a web server either...

Looks like there's the start of something workable here, but it needs a bit of
shoveling? (Or at least digging into how to configure it?)

>> > the bug is probably that it took us so long
>> > to remove this cruft. (though we've had bytes are 8 bits for a while
>> > now, and c23 finally guarantees two's complement!)
>>
>> Oooh, does it? That's nice. Does this mean the stupid compiler "optimizing" out
>> explicit checks for signed integer overflow will STOP DOING THAT?
> 
> nope... that's still
> https://thephd.dev/c-undefined-behavior-and-the-sledgehammer-guideline

I apply the sledgehammer to the compiler. (Push back against the abuser causing
the damage, don't make the victims endlessly escalate ever-changing "compliance"
that's never good enough. Danegeld encourages the dane.)

>> Rob

Still Rob