Hi, all.
I encounterd the problem that 'cdrdao' is not compilable in 2.2.18 on
Alpha. And I researched a little.
So, then new code added in include/asm-alpha/system.h on 2.2.18 has a
problem in C++. The 'new' may be the reserved word in C++. And I send
its patch.
Regards
Daiki Matsuda
[Daiki Matsuda]
> I encounterd the problem that 'cdrdao' is not compilable in 2.2.18 on
> Alpha. And I researched a little.
Then cdrdao has a problem. It should not be including kernel headers
directly. You are changing perfectly legal C.
Peter
On Mon, Dec 18, 2000 at 03:31:54AM -0600, Peter Samuelson wrote:
> directly. You are changing perfectly legal C.
You're right that's not kernel issue and patch can be rejected, but he's not
really changing anything :). If changing that helps then it's a compiler bug.
Andrea
[Peter Samuelson]
> > You are changing perfectly legal C.
[Andrea Arcangeli]
> You're right that's not kernel issue and patch can be rejected, but
> he's not really changing anything :). If changing that helps then
> it's a compiler bug.
Not a compiler bug, a source bug of assuming a C header file can be
included by a C++ program. The right solution, as always, is to make a
copy of the header (assuming you really do need it) and edit the copy
as necessary. This is a simple variation on the #ifdef __KERNEL__
issue.
Peter
On Mon, Dec 18, 2000 at 09:03:00AM -0600, Peter Samuelson wrote:
> Not a compiler bug, a source bug of assuming a C header file can be
> included by a C++ program. [..]
C++ obviously doesn't care about the name of parameters in a function too.
Andrea
[Andrea Arcangeli]
> C++ obviously doesn't care about the name of parameters in a function
> too.
Sure it does when they are language keywords. In this case he is
trying to change the parameter name "new".
Peter
On Mon, Dec 18, 2000 at 09:24:17AM -0600, Peter Samuelson wrote:
> Sure it does when they are language keywords. In this case he is
> trying to change the parameter name "new".
Ok ;)
Andrea
** Reply to message from Peter Samuelson <[email protected]> on Mon, 18 Dec
2000 09:03:00 -0600 (CST)
> Not a compiler bug, a source bug of assuming a C header file can be
> included by a C++ program. The right solution, as always, is to make a
> copy of the header (assuming you really do need it) and edit the copy
> as necessary.
That just creates more maintenance problems. What if the kernel header file
changes? Then he'll have to change his copy as well. He'll forever need to
check changes in that kernel header file, or risk having an obscure bug that's
otherwise hard to track.
Yes, it's perfectly valid C, but so what? That doesn't mean that it's a good
idea. It does no harm to make a minor change to the header file to allow a C++
compiler to digest it. I consider it to be a "professional courtesy" of a C
programmer for a C++ programmer. All the C programmer needs to do is
acknowledge that someone might want to use a C++ compiler on the code, and just
make a few minor changes that have no negative affect at all.
--
Timur Tabi - [email protected]
Interactive Silicon - http://www.interactivesi.com
When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me.
> programmer for a C++ programmer. All the C programmer needs to do is
> acknowledge that someone might want to use a C++ compiler on the code, and just
> make a few minor changes that have no negative affect at all.
All C++ folks need to do is to use
extern "C" {
#include "macrosforthestuffthecplusplusstandardspeoplegotwrong.h"
#include "cheaderfile"
#include "nowmakethemacrosgoaway.h"
}
where those redefine new private etc
In article <[email protected]>,
Timur Tabi <[email protected]> wrote:
>** Reply to message from Peter Samuelson <[email protected]> on Mon, 18 Dec
>2000 09:03:00 -0600 (CST)
>> Not a compiler bug, a source bug of assuming a C header file can be
>> included by a C++ program. The right solution, as always, is to make a
>> copy of the header (assuming you really do need it) and edit the copy
>> as necessary.
>
>That just creates more maintenance problems. What if the kernel header file
>changes? Then he'll have to change his copy as well. He'll forever need to
>check changes in that kernel header file, or risk having an obscure bug that's
>otherwise hard to track.
No, in fact that is the desired behaviour. If the kernel include files
change, chances are very big that the source of the utility (or library)
needs adjustments as well. In fact if you simply recompile the old
source with the new header files you might get unwanted and unexpected
behaviour, whereas if you recompile with the older header defs you'll
simply use an advertized api that might not be the latest but works
Mike.
--
RAND USR 16514