[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> In this way, the previous code could simply be written:
> ustrzncpy(s2, sizeof(s2), s1, n);
I didn't see it before, but this was exactly the case in src/file.c:322
> We would end up with a compliant subset of ANSI C: ustrlen(), ustrcpy(),
> ustrncpy(), ustrcat(), ustrncat(), usprintf() and their size-aware
> counterparts: ustrsize(), ustrzcpy(), ustrzncpy(), ustrzcat(),
> ustrzncat(), uszprintf().
The new API is in the CVS tree (the patch is located at
http://www.multimania.com/ebotcazou/new_unicode_api.zip (~26k), I didn't
want to annoy those Australian guys with very limited mobile phones ;-)
What has changed:
- the 'n' formal parameter always mean number of actual (non-zero)
characters, not bytes (ustrncpy, ustrzncpy, ustrncat, ustrzncat, ustrncmp),
- the 'size' formal parameter always mean *total* size in bytes, *including*
the terminating NULL character, so that the former
ustrncpy(dest, src, sizeof(dest) - ucwidth(0));
ustrncat(dest, src, sizeof(dest) - ustrsizez(dest));
write now:
ustrzcpy(dest, sizeof(dest), src);
ustrzcat(dest, sizeof(dest), src);
- the 'z' functions are the size-aware counterparts of the non 'z' ones and
*always* append the terminating NULL character; therefore ustrncpy() and
ustrzncpy() behave differently when the source string is longer than 'n-1'
characters.
When propagating the changes, I found two little bugs in unix/usystem.c and
beos/bsystem.c relating to the manipulation of the former ustrncat()
function. Thanks to the unixification of the MacOS port by Peter, I was able
to update it as well. And I'm almost done with the unicodification of the
setup program.
--
Eric Botcazou
ebotcazou@xxxxxxxxxx