Re: LDAPMod field types

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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.

-- 
Regards,
Hallvard