[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: libkopete/avdevice
From:       Thiago Macieira <thiago () kde ! org>
Date:       2005-05-27 23:43:34
Message-ID: 200505272043.43839.thiago () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Luke-Jr wrote:
>> Yes. All distributions should have sanitised kernel headers.
>
>And where should these 'sanitised' headers come from?

Most distributions already keep a local copy of sanitised headers. As far 
as I know, there is no central "sanitised kernel headers project" -- just 
distributions exchanging patches against some kernel release or another.

The URL for the PLD's sanitised version was posted to this list last time 
this subject came up.

>> At least some of them do, since they are included by glibc's standard
>> headers.
>
>glibc is also a C library-- no reason to expect it to work in C++, is
> there?

There is, since the standard C++ headers (cstdlib, cstddef, etc.) include 
the glibc headers. So, yes, the glibc headers must be C++ compatible.

Fortunately, they are, even to the point of adding throw() for the 
function declarations.

>> If we should be including them in our programs, that's another story.
>> Personally, I much prefer copying the relevant structures and
>> constants into a private header.
>
>Sounds like a good solution. In the meantime, where should I get a
> working header from?

The archives for kde-devel has the URL. I don't remember it by heart.

However, I do think it still contained variables named "new".

-- 
  Thiago Macieira  -  thiago (AT) macieira (DOT) info
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se 
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]