Considering making the code C++ portable
rra at stanford.edu
Tue Jan 9 00:54:24 UTC 2001
Forrest J Cavalier <mibsoft at mibsoftware.com> 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
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 stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers