Considering making the code C++ portable

Russ Allbery rra at
Wed Jan 3 20:30:49 UTC 2001

Steve Prior <sprior at> writes:

> Actually I've been doing pretty much exactly as you mention.  Today I
> did one pass of removing C++ reserved words used by INN headers as
> member values - private and class were the problem ones.

I'd happily accept a patch for this, although I'd rather just rename the
members to something else completely instead of adding underscores around
the words.  But what to rename them to would depend on where those
reserved words are being used.

> BTW I've run into a few K&R style function declarations there so it
> would certainly be some amount of work to finish.

Feel free to submit patches to get rid of any of those that are lingering;
they should all go away.

> To be truthful I'd be happy (or so I always promise) if I could compile
> innrpd in C++ because my nature is to use C++ classes for my custom
> stuff, but I don't think that INN development is planning to shift into
> requiring a C++ compiler anytime soon.

Likely not; I detest C++.  :)

> I do think that since C++ even on non-OO code is a more strict compiler
> that it will help shake out those bugs you implied are in there
> somewhere and make the code better even it really stays C code, and
> doing so shouldn't break any ANSI C compiler in use today.

> Do you agree?

Hm.  Not really.  Beyond a certain level of stuff like ANSI prototypes and
no implicit casts, which you can also get from a decent C compiler with
warnings turned on, C++ compilers are more different than really stricter
when compiling C code.  There are certain constructs used widely in INN,
such as implicit casts to and from void *, that are perfectly valid C and
*shouldn't* be turned into explicit casts, but which C++ will complain
about IIRC.  Although I've not done anything with C++ for quite a while.

Russ Allbery (rra at             <>

More information about the inn-workers mailing list