Re: [9fans] Plan9 development

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>]

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/