Bernd Jendrissek writes:
44 modFormat.mod_type = "rocketseedFormat"; 45 vformat[0] = "2"; (...) rscode/rocketutil/mydap.cpp:44: warning: deprecated conversion from string constant to 'char*' rscode/rocketutil/mydap.cpp:45: warning: deprecated conversion from string constant to 'char*'
Are we risking some sort of free()-based crashes by populating the struct with string constants?
No. You built the structure, you clean it up.
Would it be safe to const_cast<char *> the string constants,
Yes.
or will I need to wrap each with a strdup() and ldap_mods_free() it all after we're done?
No. ldap_mods_free() is just a helper function you could use if you did build the structure with malloc and strdup. Or better yet, with ber_memalloc and ber_strdup. (These are wrappers needed on Windows or something because IIRC memory must be freed by the same DLL which allocated it.)
This is just a case of "const poisoning" - once you slap a "const" at a declaration, it can easily spread out, demanding "const"s elsewhere too. C started out without "const", even on string literals (which may not be modified). C libraries and programs do tend to grow more consts over the year, but C++ has gone much farther. For one thing, because it has features like const_cast<> and mutable which make unwanted consts less painful.
When defining a library data structure, one has to decide on things like what to constify. The API has no reason to assume that the data is intended to be const - in fact, ldap_mods_free() would look strange if it was. Stranger than in C++, anyway.