Follow-up Comment #1, bug #19388 (project freeciv):
(Further explanation of the perceived problem here
I'm still not sure I understand the problem, but I suspect it comes from
compiling Freeciv as C++ rather than C. They're not the same language.
'*buf' is the only pointer-to-const here. It's true that 'ptr' can end up
pointing into '*buf' despite 'ptr' not being a pointer-to-const; it gets
'laundered' through strpbrk(), which is declared in C as
char *strpbrk(const char *s1, const char *s2);
However, there's no code path in which 'ptr' is written through when it does
point directly into '*buf'; it's only written through when 'dest'
(pointer-to-non-const) is non-NULL, and in that case 'ptr' was previously set
to into 'dest', not '*buf'. So "morally" it's OK (modulo aliasing, clever
The fishiest thing I see here is strpbrk() washing away const-ness, but that's
how it's defined in the C standard, and I can see why (you want to be able to
pass a non-const to it and write through the resulting pointer). What you
really wanted was for the library function to propagate the const-ness
through, but you can't do that in C.
However, as I understand it, you're compiling as C++. A random Google hit
<http://www.cplusplus.com/reference/clibrary/cstring/strpbrk/> suggests that
strpbrk() in C++ is defined using function polymorphism, so that the
const-ness _can_ be propagated through the function. I think that is what is
leading to your problem. We get away with it in C because C isn't expressive
enough to express the right semantics for its own standard library, I think.
I don't think it's a goal of the bulk of the Freeciv code to be both valid C
and C++ (although we strive for C++ compatibility in header files).
Reply to this item at:
Message sent via/by Gna!
Freeciv-dev mailing list