freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] freetype-2.3.7 -- ftconfig.h for biarch systems


From: mpsuzuki
Subject: Re: [ft-devel] freetype-2.3.7 -- ftconfig.h for biarch systems
Date: Wed, 9 Jul 2008 13:47:57 +0900

On Tue, 8 Jul 2008 22:56:12 +0200
Antoine Leca <address@hidden> wrote:

>On Wednesday, July 2nd, 2008, mpsuzuki noted:
>> On many platforms, gcc does not set the value __STDC_VERSION__
>> by default. Users have to set by -std=xxx option.
>
>On the other hand, it does not seem unreasonable to me to *require* bi-arch 
>compilers to operate in C99 mode, providing this is adequately documented: 
>as far as I understand, 32/64 bi-arch compilers are normally recent, so C99 
>ought to be available even if it is an option (as you pointed out for GCC 
>3.x)

Hmm, if C99-dependent bi-arch header file is installed as
a part of FreeType2, I'm afraid that all softwares using
FreeType2 should be compiled with C99-conforming C compiler.
And, C99-unconforming C compiler should be refused (or warned
at least) during the compilation including FreeType2 header.
I think it's not welcomed except of the developers on the
platforms whose compiler works in C99-mode by default.

# Think about the case I use legacy commercial C compiler
# designed for i386, in GNU/Linux on amd64.

As I've written in previous posts the size checking of long
type is important to keep the compatibility with previous
releases. Even if we restrict the scope to C99-conforming
cpp, there is no portable cpp conditional to check the size
of long. So, still careful and fine conditionals are required,
the advantage to restrict the scope to C99 is not clear for
me. How do you think of?

Anyway, I have no objection to refine the APIs of FreeType2
with C99-like type definitions in next major release,
because we can introduce binary-incompatible improvement.

Regards,
mpsuzuki




reply via email to

[Prev in Thread] Current Thread [Next in Thread]