[sane-devel] SANE 1.1.0 Release discussion

François Revol revol at free.fr
Fri May 9 15:28:43 UTC 2008

> >  proprietary unices can't use gcc or another C99 compiler?
> >  Which unix in particular?
> Pretty much all of them ship compilers that do not implement C99 or 
> do
> not implement all of it yet. Moreover, we're speaking of systems that
> often do not get updated for a variety of reasons, so you can't rely
> on a recent compiler being installed or even available.
> In my experience it's actually pretty easy to make one of these
> compilers barf on what you'd consider "standard C code".
> Moreover gcc is not always an option for various reasons, one of them
> being the support contract linked to the machine. Another one would 
> be
> the total pain that is a gcc+binutils build.
> >  I'm pretty tired of those proprietary closed source things that
> >  we don't even know of and that are preventing us to improve.
> Next time you'll say that for the BSDs.
> Portability can be seen as a burden, I see it as a mean to learn a 
> few
> things along the way and make the code better. It also teaches you 
> not
> to rely on things that make life easy for you as a programmer. That
> saved me already :)

<rant of the day>

May some insane ffmpeg devs hear you !
Some of them understand "porting" as "porting the OS to their 
application", and refuse some simple workarounds on the reason they add 
missing standards stuff.
(like PRIx64 and friends, INT64_C()...)

They don't care if the OS was written before the standard, if it's 
still maintained or not... at least they didn't break gcc2 build (but 
they try :p).

One obvious example is errno codes.
BeOS has all errors declared as negative.
This has many advantages, but standards mandate them to be positive.
I don't know why Be did it that way, but the fact is they are negative 
and we can't change that.
But the fact is also that some standards changed their mind in the 
middle, like OpenGroup. One page mentions them to be "positive", but 
the changelog says they changed to it from "non zero" to match 
Csomething. Maybe Be just read this and went doing their stuff. How are 
we supposed to do now ?
And we all know standards are meant to be broken, because there are so 
many to choose from that you can't respect them all without breaking 
some other.

Usually it's not a big problem, except in some projects where linux-
only ppl write error handling... they then use the same trick that the 
kernel does, that is return -EFOO. Of course that works for linux and 
others, but fails miserably in BeOS and Haiku.
I end up sending huge patches full of
-		return -EINVAL;
+		return RETERR(EINVAL);
... with only 2 lines only to actually support BeOS (usually 
AC_CHECK_LIB(m,sqrtf) because linux devs are too lazy to check for it).

</rant of the day>


More information about the sane-devel mailing list