On Jun 7, 2010, at 11:50 AM, Mark Hatle wrote: > 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. >
I was thinking "run-time" ... > For runtime, it should be a simple 'switch' for the strdup call. > ... and there's nothing "simple" about insturmenting choice in POPT underneath applications. Its either Yet Another Arcane flag that noone uses or a goosey-loosey envvar that makes debugging run-time dependent, see the tedium of POSIX_ME_HARDER that is already in POPT since forever. But sure I know the "Have it your own way!" run-time drill quite well too. Just I'm hoping not to go there, I do like KISSy-poo. >>> 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.) > What is currently implemented is the former, malloc everything returned, and those with clue will figger it out. That's general, just surprising. But I can/will make the audit's easier if that is what is desired. Its a bleeping string, deal with it, stop fussing POPT "leaks" is MNSHO privately. >>> 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. > Changing the soname or even (gasp!) using ELF symbol versioning is quite doable, all the necessary precursor elements have been in place for years. > 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.) > Hehe, so PROT_READ LART'ing is where you want to go ;-) That would be fine with me except I'm also trying to avoid any POPT "support" headaches. Note that C macros could be used to ease the pain of "long" <-> "void *" punning. But I _REALLY_ need another pointer field somehow without overloading the two i18n --help fields which are already way way way too complicated for my taste. 73 de Jeff ______________________________________________________________________ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
