Re: Patching Mandoc for IRIX

[Ingo Schwarze <schwarze@usta.de>]

Hi Kazuo,

Kazuo Kuroi wrote on Fri, Aug 28, 2020 at 03:40:26PM -0400:

> We're not looking to replace libc with say GNUlibc (oh gods no)

That makes sense to me.  Replacing the complete libc would be a very
drastic change in any operating system.  It can easily be contrary
to project goals.

> and I 
> understand the viewpoint that you don't want to pollute the code with 
> workarounds. What I am suggesting possibly would be to have your 
> configure script detect IRIX either by the preprocessor macro __sgi or 
> by uname -a output and automatically advise them to check your ports 
> page for a proper patch or something like that.

Again, i don't like testing for platform names like that.  Imagine
one day, you find a way to really fix the problem in IRIX - that could
happen even if today, you don't know yet how.  Then such a test would
deliver totally bogus advice to users, and i'm not likely to even
notice because i don't use IRIX daily.  I hate it when application
software makes libellious statements about operating systems merely
because they had a problem at some point in the past.

Also imagine somebody else has another system that also chokes on %zu.
Testing for __sgi doesn't help with that at all.

But now your input gave me a somewhat similar idea.  Maybe i should
write an automated test that detects whether printf("%zu...", ...)
works as expected, and if it doesn't, print a diagnostic message
advising the user what exactly the problem is, why it can't be fixed
automatically, and how they can fix it manually (for example, using
a patch you provide on your website).

I don't think i will do that for the upcoming mandoc realease yet...

> Give me some time to see what I can do.

 ... to give you a chance to think it through: whether that approach
makes sense to you, too.

> There's literally no chance of fixing the libc unless 
> someone comes along and writes a 100% FOSS reimplementation,
> which I'm sure we both know is wishful thinking.

It seems to me you need some way to fix at least security bugs one
way or another, and the misinterpretion of "%zun" as "something + %n"
does indeed look like a security vulnerability to me.

I'm not convinced fixing a bad bug in a single function requiires
replacing the whole library.  Even without decompiling, it is likely
possible to replace an individual buggy function in the library.
Something like

   $ ld --shared -o libc.so.new printf.o libc.so.old

might be all that is needed, maybe with a few more options, if
necessary replacing printf.o with something like vfprintf.o if it
turns out the actual bug is in that function.  Of course, you need
to write your own printf.c or vfprintf.c or whatever or grab one
from a freely licensed C library (for example a BSD one). If that
isn't possible, using a feature like LD_PRELOAD might be another
option, again only overriding functions that are actually broken,
not rewriting everything from scratch.

Either way, problems like this require solutions on the operating
system level, not on the application software level.

> Ironically, I don't have issues with %zu with GNU ports for the most 
> part,

GNU projects using autoconf are notorious for not using the printf(3)
implementation from the native libc.  Autoconf does tests for some
subfeatures of printf(3), is extremely picky about the results,
usually concludes the native libc is no good and proceeds to use
some bundled version of printf(3) instead.  That of course hides
potential issues and instead creates others, if the bundled (GNU)
implementation isn't fully compatible with what users expect on the
operating system in question.

I hate it, though, when application programs test for operating
system bugs (rather than whether features are supported) and then
replace components of the operating system merely because they
don't like what they see, so i'm not going to do that.

If the OS provides a function, i will use it and rely on the operating
system maintainers to make sure it works.  It is not my job as an
application developer to second-guess operating system maintainers.
This dog also bites the other way: imagine a libc function has a
common bug in all operating systems.  It is reported and all systems
fix it, but most application software (in particular programs
endulging in autoconf orgies) still suffer from it because they
considered it smart to bundle and use their own copy.  That's a
bummer, isn't it?

> and I've been developing a little code scanner to figure out how 
> to go in and catch these issues before I try compiling so I can be on 
> the lookout. It's not a bug; more like a lack of functionality. The 
> trailing n, apparently, doesn't cause issues when I remove the z format 
> specifier. I'm going to confirm that all of your %zun are for size_t, 

If you find any that aren't, please tell me, because that might indicate
a bug in mandoc...

> and I'll go in and double check that we've not introduced any nasty bugs 
> in our downstream patches. The postscript functionality I've not tested, 
> primarily because the main goal here is to avoid having to use GNU groff.
> 
> 2. __sgi vs __sgi__
> 
> __sgi is different. IRIX doesn't define __sgi__ as to my knowledge. But 
> IRIX is pretty much static at this point, so uname output and platform 
> IDs aren't going to change. AFAIK, OpenBSD no longer supports SGI 
> hardware,

Oh, you are right, the sgi port was dropped recently:

  https://www.openbsd.org/sgi.html

> so why their other MIPS ports would define that is probably a 
> bug unless it's using a straight port of IRIX n32/n64 ABIs as Linux MIPS 
> does (There's so many ABI similarities other than syscalls/libc 
> differences it's kinda uncanny).
> 
> Fair point either way, but in that case what alternatives do you 
> suggest? I think it's fair to just point us downstream if that's all you 
> can do it.

See above for another idea.

> 3. Conclusions
> 
> To end my message for now I want to explain that the reason people still 
> use IRIX is because of its uniqueness and historical value. I certainly 
> am understanding that I can't expect you to make all kinds of special 
> accomodations for us, all the same I do appreciate your help. For me, 
> and most of the community, Linux and BSD on SGI hardware misses the 
> point. Without the original environment, it's just below-average 
> underpowered hardware. if I wanted a high performance RISC system 
> without that baggage, I'd use POWER64el. So we're kinda stuck with IRIX 
> since it's a system of interest.

Oh, i see.  Yes, that makes sense to me.

> For now, I'll check the latest CVS revisions, see if that solves some of 
> the issues mentioned, and I'll do some more extensive testing just to 
> verify if I have any more issues. Will take me a bit of time before you 
> hear from me again!

Sure, there is no hurry.

I appreciate that you consider and investigate all this seriously.

We can probably iterate a bit, both sides moving closer to the
other in baby steps (a bit of detection on my side, smaller and
cleaner patches on your side, even more bits of detection here,
even smaller and cleaner patches there, and so on), but it need
not be finished next week.

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv