GNOME Bugzilla – Bug 455352
Provide g_renew0()
Last modified: 2007-07-09 23:46:54 UTC
I saw code like this recently: hb_glyphs = g_renew(HB_Glyph, hb_glyphs, shaper_item.num_glyphs); hb_attributes = g_renew(HB_GlyphAttributes, hb_attributes, shaper_item.num_glyphs); hb_advances = g_renew(HB_Fixed, hb_advances, shaper_item.num_glyphs); hb_offsets = g_renew(HB_FixedPoint, hb_offsets, shaper_item.num_glyphs); hb_logClusters = g_renew(unsigned short, hb_logClusters, shaper_item.num_glyphs); memset(hb_glyphs, 0, shaper_item.num_glyphs * sizeof(HB_Glyph)); memset(hb_attributes, 0, shaper_item.num_glyphs * sizeof(HB_GlyphAttributes)); memset(hb_advances, 0, shaper_item.num_glyphs * sizeof(HB_Fixed)); memset(hb_offsets, 0, shaper_item.num_glyphs * sizeof(HB_FixedPoint)); That calls for g_renew0().
a g_renew0 that 0-ifies the newly allocated memory can not be implemented without adding extra allocation overhead which is undesirable in most cases. that's because glib has no means to access the size of the previously allocated block. the size is only known to the underlying allocator and unretrievable (unfortunately - i've whished for this a couple of times myself already). the alternative, a g_renew0 that 0-ifies all allocated memory would come as a surprise in most cases and thus be undesirable (g_new0 can easily be used instead).
I was thinking of zeroing just the new length that user passes in. That's the part the user is interested in anyway. Of course zeroing memory after g_renew() sound kinda silly, but this idiom (of using g_renew() instead of g_new) is commonly used to reduce allocations when for example reading lines of a file one by one...