4 ms·
> I would move json_* _t structs to the header file and eliminate a bunch of API functions that service the access to these structs. It's a C library after all,
by pflanze 14y ago
> I would move json_* _t structs to the header file and eliminate a bunch of API functions that service the access to these structs. It's a C library after all, everyone knows how to shoot one's own leg.
From what I know I would suggest to only do that if the code is never to be used as a shared library, as otherwise the structs can't be changed without recompiling all programs using the library.
There was a Debian security update to libxml2 in 2008 that made various Gnome apps including, IIRC, the window manager crash for many users in various circumstances (depending on the used theme etc.)(* ), because it changed some struct. Public API functions were provided in that case, but apparently direct access to structs was not discouraged enough to prevent some programs from going the unsafe route anyway (or perhaps the API wasn't sufficiently complete? I don't know the details).
I haven't created any wide spread C programs, and don't know if there are ABI checkers that Debian should use / have used, or if it's really just restraint to procedure based APIs that can avoid such problems.
(* ) e.g.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496125 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496125
http://lists.debian.org/debian-user/2008/08/msg01864.html http://lists.debian.org/debian-user/2008/08/msg01864.html
- eps 14y agoRight. This would apply if parson were built into a shared library and distributed as an .so. It is a possibility, though Debian's package dependency system exists exactly to safeguard against this sort of a situation.