From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 757 invoked from network); 31 Aug 2020 14:12:15 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 31 Aug 2020 14:12:15 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id bdcee5e2 for ; Mon, 31 Aug 2020 09:12:09 -0500 (EST) Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 215e7194 for ; Mon, 31 Aug 2020 09:12:06 -0500 (EST) Received: from hekate.asta.kit.edu ([141.3.145.153] helo=hekate.usta.de) by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1kCkXT-0003mr-4t; Mon, 31 Aug 2020 16:12:05 +0200 Received: from donnerwolke.asta.kit.edu ([141.3.145.61] helo=donnerwolke.usta.de) by hekate.usta.de with esmtp (Exim 4.92.2) (envelope-from ) id 1kCkXR-0005e3-J6; Mon, 31 Aug 2020 16:12:01 +0200 Received: from athene.asta.kit.edu ([141.3.145.60] helo=athene.usta.de) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1kCkXR-0000Bw-Dr; Mon, 31 Aug 2020 16:12:01 +0200 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 62567009; Mon, 31 Aug 2020 16:12:01 +0200 (CEST) Date: Mon, 31 Aug 2020 16:12:01 +0200 From: Ingo Schwarze To: discuss@mandoc.bsd.lv Cc: Kazuo Kuroi Subject: Re: Patching Mandoc for IRIX Message-ID: <20200831141201.GE92167@athene.usta.de> References: <20200622214406.GD93760@athene.usta.de> <20200827180924.GG28751@athene.usta.de> <2c74d173-4bbb-7837-9f6f-29441c74b8da@irixnet.org> X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c74d173-4bbb-7837-9f6f-29441c74b8da@irixnet.org> User-Agent: Mutt/1.12.2 (2019-09-21) 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