ClusterLabs
WIP: Refactor: libcrmcommon: Introduce GString for XML
WIP
Update xml.c and acl.c to use GString in a couple of places for
dynamic allocation. Eliminates risk of overflowing char array.
Resolves: RHBZ#1822125
I'd like to get maintainers' thoughts on the general approach so far
before I go any further with refactoring to use GString.
Jenkins build is failing due to a build system issue. Travis and Coverity passed on the current build.
I think the current version covers all the offset += snprintf() instances in xml.c and acl.c. Ken mentioned in the BZ:
I've considered switching to glib's GString to replace both buffer_print() and offset+=snprintf()
We can certainly refactor or replace buffer_print() with an implementation that uses GString. But somewhere down the line, we're going to have to strdup() the GString to get a C string. Otherwise, we end up either mixing glib and C memory management, or changing the public-facing interface. I don't see a way around doing one or the other. For example, the following functions are public and return char *:
-
dump_xml_formatted_with_text -
dump_xml_formatted -
dump_xml_unformatted
They all call crm_xml_dump, which calls buffer_print and other functions that also call buffer_print. So buffer_print will bubble up to the public interface, and the GString would need to be converted. I haven't benchmarked it, but that seems like it could be a whole lot of added strdups compared to what we have now. I wonder what effect that might have with a large CIB.