[ft-devel] strncpy() [Was: Bug in ft_mem_strcpyn]

[Antoine Leca]

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