> -----Original Message-----
> From: pcp-bounces@xxxxxxxxxxx [mailto:pcp-bounces@xxxxxxxxxxx] On
> Behalf Of Frank Ch. Eigler
> Sent: Wednesday, 23 April 2014 5:39 AM
> ...
> This change is backward-incompatible, so any older binaries would likely
> result in memory corruption when run against the new shared library. We
> could say that it doesn't matter, that the symbol is "internal", etc.
Frank is correct. This is a case where I was being lazy and not "doing as I
say". My only excuse is I fixed all the uses of __pmLogPutResult in the PCP
source, and could not imagine anyone else using this method.
But, that's not the "right" attitude.
> Or we could fix it. The function with the new requirement could be
renamed
> __pmLogPutResult2. The older __pmLogPutResult symbol could be replaced
> by a wrapper that does an internal memory-copy, or something else safe.
Yep +1 for __pmLogPutResult2 ... I'll fix it.
We don't need anything different, just the old implementation ...
> We could even inoculate against such future problems to some extent.
> "internal" utility functions could be formally identified (since the "__"
naming
> prefix is not that). They could be excluded from shared libraries and
installed
> documentation, and built only as .a files.
> The export files for future versions of PCP shared libraries could be a
lot
> smaller.
Sounds like more work ... if I'd done this correctly the first time, we
wouldn't need to be having this discussion.
|