Considering making the code C++ portable

Russ Allbery rra at
Tue Jan 9 00:54:24 UTC 2001

Forrest J Cavalier <mibsoft at> writes:

> "new" is used as an identifier in some places as well.

> I hope Katsuhiro and Russ agree to this, under the condition that you do
> it for all the INN source.

> I think that the timing for these changes is very good.  The only reason
> not to do it is because it will break patches: (This is going to touch a
> lot of the source code.)  In the last few months there were commits
> which touched a lot of the source already.

The problem that I have with doing this is that C and C++ are very much
not the same language and that converting INN's source base to C++ from C
(which is basically what this is) can cause other problems when compiled
with a C compiler.

The canonical example is a function returning a void *, which in C++ I
think has to have its return value cast when assigned to some other

    char *p;
    void *do_something(void);
    p = (char *) do_something();

The way to correctly write that in C is:

    p = do_something();

without the cast.  You don't want the cast in C code because if you later
change the void * to a dstring * or something, C will then properly
diagnose the mismatch, whereas if you cast it, C will silently swallow it
and segfault at runtime.

C and C++ are diverging as languages, not converging.  I guess I'm
unconvinced of the utility of converting INN's code to the greatest common
denominator, particularly given that the people working on INN are all
using C compilers and it's going to drift again, plus we'd be losing some
valuable features of C compiler checking by needing to do stuff like the

Of course, I could also be wrong about C++ needing the casts, in which
case maybe there aren't as many divergences as I think there are.

Russ Allbery (rra at             <>

More information about the inn-workers mailing list