From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4CE0BF9B.5040700@gmx.net> Date: Mon, 15 Nov 2010 06:05:31 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090410 SUSE/1.1.18-0.1 SeaMonkey/1.1.18 MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <703b2539-027e-4f9f-a739-00b59f6d3d82@v28g2000vbb.googlegroups.com> <20101113192425.GC22589@nibiru.local> <20101114091030.GA793@polynum.com> <4CDFBF0D.1060604@gmx.net> <2972B139-9F41-4F6F-B906-7249E0B5CCCF@vaughan.pe> In-Reply-To: <2972B139-9F41-4F6F-B906-7249E0B5CCCF@vaughan.pe> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Plan9 development Topicbox-Message-UUID: 7e84bf72-ead6-11e9-9d60-3106f5b1d025 On 15.11.2010 05:29, Gary V. Vaughan wrote: > On 14 Nov 2010, at 17:50, Carl-Daniel Hailfinger wrote: > >> On 14.11.2010 10:10, tlaronde@polynum.com wrote: >> >>> Furthermore, the auto* and libtool were typically made >>> for trying to do something "working" to some extend with a chaotic >>> source. They typically manage to compile "things" written by >>> programmers who have been encouraged to look at the finger ignoring >>> the moon: to concentrate on the "GNU" tools and "GNU" libraries >>> etc, and not on C89 (or C99), POSIX etc. >>> >>> >> Heh. Pure C99 code (with no GNU extensions or OS specific stuff >> whatsoever) doesn't compile with pcc unless you avoid some of the really >> useful features and some of the standard headers. I can quote the C99 >> standard if you doubt this. >> > > Even then, many vendor compilers and linkers have many non-conformances, > and outright bugs. Take a look at the number of workarounds that make > their way into gnulib to cover breakage in the POSIX APIs alone. > > You can either try to remember what all of those are, or use something > like autoconf to probe for known bugs, and gnulib to plug them, or > you can link against a shim library like GNU libposix which will > do all of that automatically when it is built and installed, allowing > you to write to the POSIX APIs with impunity. > Oh, I don't doubt that there is lots of API breakage on various unixes. However, I hope that printf, scanf, fopen and similar basic functions are working well in all those environments. That said, non-portable constructs like mmap have to be avoided (or at least wrapped in some cross-platform interface) once you want to run software on Windows. And AFAIK hardware accesses are totally non-portable anyway. libpci/pciutils and X.org have their own abstraction layer for this, and flashrom uses its own abstraction layer as well. I have yet to find a general purpose library which handles hardware accesses and works on DOS, Windows, *BSD, Linux, Solaris, MacOSX, ... X.org might be close, though. >> I have successfully avoided using autoconf and similar stuff in my >> projects by adhering to strict C99, but in an ironic twist of fate, Plan >> 9 will be the OS that forces me to use something like autoconf due to >> the limited C99 support. >> > > And sadly, there is a good chance that your blind faith in having fully > conformant APIs would come unstuck quite quickly if your code needed to > work on a large selection of commercial UNIX releases (assuming you > didn't code around all of those shortcomings in each of your projects > that is). > > Plan 9 is far from alone in having limited C99 and POSIX API support. > So far this has not been a problem for flashrom, but that may also be due to the really small number of commercial unixes being supported by flashrom (no user interest, and thus pointless to port). That said, having a full-featured compiler like clang or gcc available allows coding for the compiler, and only to a lesser degree for the OS. The good thing about flashrom is that it uses only very few interfaces, and most of those need platform specific handling anyway. Writing userspace software with a nice GUI and all sorts of bells and whistles is probably a lot more prone to exercise broken code paths in libraries than an app which has no interactive behaviour and avoids pretty much every convenience feature. For such GUI apps it makes a lot of sense to use an abstraction layer which hides/replaces broken functionality in the envoronment. Regards, Carl-Daniel -- http://www.hailfinger.org/