Review needed: Add support of lzma in KDE

[Thiago Macieira]

Per Øyvind Karlsen wrote:
>Søndag 24 august 2008 18:54:07 skrev Thiago Macieira:
>> Per Øyvind Karlsen wrote:
>> >For '#define __STDC_LIMIT_MACROS 1',  this is needed by
>> > LZMA_VLI_VALUE_UNKNOWN which is defined the following way in
>> > lzma/vli.h: '#define
>> >LZMA_VLI_VALUE_UNKNOWN UINT64_MAX'.
>> >I guess the best way to avoid dependency on C99 macro and to stay
>> > easily understandable is to change '#define __STDC_LIMIT_MACROS 1'
>> > to '#define UINT64_MAX (uint64_t)-1'.
>>
>> That's not a solution either. There may be a header defining
>> UINT64_MAX. If you define it, there will be a compilation error.
>
>I guess using #ifndef wouldn't be acceptable.
>
>> No. Report as an error to the lzma developers if their header doesn't
>> work when included all by itself.
>
>Yes, probably makes sense to solve it there in stead.
>Any suggestions for any standard macros equivalent to ie. __WORDSIZE
> that could be used to avoid arch specific headers?

Well, since "long long" is a C99 feature anyways, there is no 64-bit 
integer in C89. If they want to make their code work only on C99 
compilers, that's their choice. Technically, C99 code isn't allowed in 
C++98, but it works in gcc/Linux and it'll work in other gcc platforms as 
long as the headers are present. I don't know about the Solaris and 
Microsoft compilers.

But, again, that's a choice they make. If we do just #include <lzma.h>, it 
should include all features and not generate a compiler error. (provided, 
of course, that the environment is C99-compatible, if necessary)

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080825/59522f6e/attachment.sig>