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. > 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 ... > 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: 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