That is totally irrelevant to the bug at hand (well, probably not completely ;-)), but I cannot resist such an offer... Sorry to ALL the people out there which already know that stuff.
James Cloos wrote: > and probably is most often called by way of the macro: > > ,----(freetype2/include/freetype/internal/ftmemory.h) >> #define FT_STRCPYN( dst, src, size ) \ >> ft_mem_strcpyn( (char*)dst, (const char*)(src), (FT_ULong)(size) ) >> `---- > > I suspect most users expect the same semantics as strncpy(3), in that > at most size octets are copied. Perhaps you know it, but the semantics of strncpy(3) are NOT the same: with strncpy(3), always exactly SIZE byte are written, and if the string src is shorter, it is padded with 0. Which has two bad problems associated (which are probably David's reasons to introduce ft_strcpyn): * first, if src is longer than size, it'll NOT nul-terminated with strncpy (while the earlier strcpyn silently overwrote); usually, this does not happen often. * second, strncpy has a penalty by being required to put 0 byte in potentially huge buffers; and this does occur frequently. David, perhaps it could be useful to replace, when available, your function by strlcpy (of OpenBSD fame), which does the intended (plus returns the actual size needed for a full copy), but might also be implemented in an optimized way? Antoine _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel