Re: Fwd: Re: Fwd: Re: Depending on C99 (Re: GtkBindingSignal cha

[Michael Natterer <mitch gimp org>]

On Thu, 2006-01-05 at 10:42 -0500, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN
wrote:
> >does this make? there is no reason why software from the year 2006
> >needs to be compiled with compilers from the year 1986.
> 
> cc: Sun C 5.5 Patch 112760-09 2004/03/31
> 
> That does not look like a compiler from 1986 to me. I said we disable c99 
> features for internal reasons. When you are dealing with millions of lines of C 
> code (some of which have not been modified since 1986), simply enabling a 
> compiler to use c99 is not acceptable without spending a lot of time cleaning up
>  code.

So what about just opening up that code and see how fast it will be
fixed? You are using the benefits of getting open source software for
free, while at the same time blocking its progress for your very
own closed-source reasons. I suggest you make an internal copy
of glib and just let it bit-rot then.

> We do not use glib/gtk as shared libraries, therefore the archives need to be 
> built using our standard build process which mandates how the compiler is 
> invoked.
> 
> Remember: Just because c99 is a 'standard' does not mean it is standard in 
> practice. CSS is a 'standard', but IE is so full of bugs, everyone codes to the 
> buggy software rather than the 'standard' because IE is _standard_, not CSS. 

And another example from the nice world of closed sources. There is a
piece of buggy software, unfortunately it's closed source and its
maintainers refuse to make it standard compliant.

The solution is to simply adopt to that brokenness? No, thanks :-)

> Good developers understand this and write code which is portable and works in 
> IE, Firefox, and every other random browser.

Everybody coding portable software against glib has been doing this all
the time. Just as everybody would be able to use K&R-style C syntax
if there was a need to do so. It doesn't hurt to update to new standards
from time to time. Eternal backward compatibility does no good to any
kind of software.

>  In my opinion, glib _is_ the buffer
>  between different platforms and compiler versions. If glib itself starts 
> becoming platform/compiler centric (which it seems to have avoided at all costs 
> up to this point), then much of that benefit is lost.

Absolutely agree here. It's simply a question of the a minimum set of
features to agree upon. This set needs to be updated from time to
time, and closed-sourse in-house software that has not been updated
for like 20 year doesn't sound like a good reason to hold back
progress.

ciao,
--mitch