On 9 May 2014 13:58, Arturo Borrero Gonzalez <arturo.borrero.glez@xxxxxxxxx> wrote: > We need to store in 'offset' the complete amount of characters as returned > from _snprintf. The value means how many characters long needs the buffer to be > in order to store the corresponding string expansion. > > Before this patch, in cases where the buffer is smaller than the > expansion, then ret > len, and therefore ret = len. > So when incrementing offset, we do it with a wrong value. > > All previous versions of libnftnl are unable to handle this situations: small > buffers (or long string expansion). > > BTW, if a caller must reallocate a buffer to the returned value of snprintf, it > should be ret + 1. > About this issue: We use mostly fprintf() functions in our test infrastructure. While _fprintf() functions use internally _snprintf() [0] (thus, allocating a 4096 sized buffer in the stack), this is done *per object*. A single object hardly can contain more than 4096 characters when string-expanded (either JSON or XML). Also, this problem arises strongly with a big nft_ruleset printed with nft_ruleset_snprintf(), because there no single buffer is allocated per object. OTOH, printing the same nft_ruleset with nft_ruleset_fprintf() will result again in allocating single buffers per object [1]. Regarding the reallocation [2] of ret + 1, that fix will come in a different patch. The example provided in the snprintf(3) manpage also reallocs with +1, as snprintf adds a trailing \0. regards. [0] http://git.netfilter.org/libnftnl/tree/src/utils.c#n188 [1] http://git.netfilter.org/libnftnl/tree/src/ruleset.c#n970 [2] http://git.netfilter.org/libnftnl/tree/src/utils.c#n199 -- Arturo Borrero González -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
