Jeff Johnson wrote:
On Jun 7, 2010, at 10:37 AM, Mark Hatle wrote:
The way I've usually addressed this is to either add an option to the library
that changes the default behavior from strdup to passing the address with the
expectation of const.
I'd rather _NOT_ go the "Have it your own way!" route in
a API/ABI becuase it adds yet another datum that needs to
be extracted from lusers doing POPT support.
Runtime not build time. For a library like popt, build time would be really
bad.
For runtime, it should be a simple 'switch' for the strdup call.
Either by adding const style prototypes/functions, or by using some mechanism
to change the behavior of all of the functions.
(aside)
Well I've gone multiple ways with the C borkage of "const char **"
vs "char *const *" in POPT and RPM. These days there's so much spewage
from GCC that I don't believe that compilers or language hints solve
any "real world" issue. But I can/will go to PROT_READ mandatory hardware
enforcement using mmap(2) if that is what is desired. Its easier
to implement the code than it is to discuss the various religion's
coding fetishism's Yet Agin. But I digress ...
Note that it _WAS_ GCC's writable strings that forced the malloc
into POPT in the first place, where POPT sometimes returned
strings from RO memory, and sometimes from argv, and the morons were confused.
Adding the strdup() to POPT was 1 less issue to worry about. Another digression
...
Ya, I don't doubt it. I believe the issue comes down to consistency. Either
everything popt returns should be duplicated so that the user has to clear them,
or nothing should be so the user knows that it's expected to be read-only.
(Enforcing read-only is another issue entirely, and one that I don't really
think is popt's responsibility. Set the prototype properly on the functions and
if the user violates them so be it.. they live with the consequences.)
My biggest concern is the potential retrofit of existing apps that expect the
current behavior.. but I agree with many of the submitters.. popt really should
be sending const points and then the app needs to strdup.
And so "legacy compatibility" again again again. POPT 2.0 is a major change
with no "compatibility" implied or intended. Meanwhile I will strive to
make the change as painless as possible. But there are issues (aka "deep hacks")
that have been in POPT for a decade that aren't the right thing to do. And even
though I've overloaded just about everything possible in the 7-tuple of a
POPT table item, there are these issues:
If both popt 1 and popt 2 can live on the same machine and have different
sonames, then I vote for no strdup.. it's the users problem to duplicate what
they want.
IMHO libraries should not protect the user from themselves. If they are dumb
enough to modify memory or expect that memory will live beyond a certain
pre-defined lifecycle.. then it's their problem to fix... (Note of course
reentrancy and such could be an issue.. but thats only a problem if it's allowed
by popt.)
--Mark
0) overloading with bit masks and long <-> void * punning is quite
mysterious to most.
1) bits in certain fields are _ALREADY_ ambiguous for certain values,
with
subtle "conventional" contextual tests of other entries needed while
using POPT.
2) there's a need for Yet Another Pointer for callbacks with context
(changing item #5
from "int" to "long" would suffice but is "instantly incompatible" so
I'd rather do something
less mysterious).
Thanks for comments however. And ignore my scarcasm if it offends.
73 de Jeff
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
