Sean McBride [EMAIL PROTECTED] writes:
Neither are currently included in glibc (and some effort with google
seems to indicate this is likely to stay this way for the foreseeable
future)
Really? Oh well, that sucks. :)
If you're interested in this sort of thing, it's probably a good idea to
Uses of ft_strcpy and ft_strcat could also be replaced with the
strn* varieties, which would be some improvement.
Agreed, the 'n' variety is not as good as the 'l' variety, but
better than the status quo.
Patches, please. :-)
Note, however, that I'm not aware of a place where strcpy is
While trying to track down an evince crash (see
http://bugzilla.gnome.org/show_bug.cgi?id=403791) I appear to have
found an error in freetype, and I've got a patch to fix it.
Applied, thanks.
Werner
___
Freetype-devel mailing list
On 2007-02-06 17:28, Tom Parker said:
The strcmp is done without checking that the return value was sane, and
strcmp(), eh? That made me curious
I searched the freetype code for strcpy() and found it is used (by way
of ft_strcpy()) quite a lot. strcpy() is evil. Someone might want to
Sean McBride wrote:
ft_strcpy, ft_strncpy - strlcpy
ft_strcat - strlcat
Neither are currently included in glibc (and some effort with google
seems to indicate this is likely to stay this way for the foreseeable
future), and so if freetype wants to use those it would have to maintain
it's
While trying to track down an evince crash (see
http://bugzilla.gnome.org/show_bug.cgi?id=403791) I appear to have found
an error in freetype, and I've got a patch to fix it. Stack trace
without the patch is as follows:
#0 0x40d83d5a in strcmp () from /lib/tls/i686/cmov/libc.so.6
#1
