New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removed userdata and custom-serialization functions #141
Conversation
…le that was only applied to the json_object module
…alls to the user-supplied buffer are necessary
…izer has been removed from the public API
These changes dropped several symbols from the library. This is an ABI break (and a API break as well, fwiw) but you forgot to bump the soname. |
Actually, I bumped the version, but I overlooked that the PR removed things
that were deemed part of the public API. So I incremented and not reset the
age. So unfortunately not a simple "forgot it" ;-)
I can re-release with a new version number if we think this makes sense. On
the other hand, as laid out in the PR, most probably nobody used these
functions as they were largely unusable by design.
Am 16.10.2017 17:00 schrieb "Michael Biebl" <notifications@github.com>:
… These changes dropped several symbols from the library. This is an ABI
break (and a API break as well, fwiw) but you forgot to bump the soname.
Fortunately, rsyslog is apparently the only consumer of this library atm
and doesn't use those symbols.
Next time please do bump the soname in such cases though!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#141 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABadi6KFVr7VrzQNVfCjmVnuhUEqupTkks5ss2-EgaJpZM4OaHA6>
.
|
I would always bump the soname in such a case, even if you think that it's unlikely that anyone uses the API, simply because it doesn't cost us alot and avoids any potential problem. As I mentioned: ttbomk rsyslog is the only consumer of libfastjson and it doesn't use the symbols. So, yeah, we might get away with not bumping the soname this time, but please consider doing it the next time something like this happens. |
Hello Rainer,
We have discussed this a year ago or so. The library uses the concept of "userdata" and "custom serialization functions" that can be set from user space. However, to effectively make use of this feature, a user must have a deep understanding of the internal data representation of the library, which makes this feature not very useful.
But what is worse: internally, the library itself also sometimes assigns data to this userdata member (especially when working with doubles), and it also sometimes assigns alternative serialization functions. This makes the feature even more unusable, because as a user you never can know when the userdata pointer is save to use for your own settings, and when you must leave it alone because it is used by the library.
Long story short. In this pull request I got rid of the userdata pointer completely. The case where the library was using the "userdata" (for storing the original string representation of a parsed double) has been moved into the union that is already used for storing values.
Can you merge this into the master branche, so that our branche and yours stay close to each other?
And: can you add to the README an explanation on how to run the tests?
Emiel