%% Stepan Kasal <kasal@xxxxxx> writes: sk> On Tue, Apr 25, 2006 at 08:51:48AM -0400, Paul D. Smith wrote: >> %% Paul Eggert <eggert@xxxxxxxxxxx> writes: pe> In fact, come to think of it, I wouldn't use str* at all, since the pe> functions you're talking about work on arbitrary memory buffers pe> that can contain internal NULs. >> I was going to protest at first: strncat() checks for both nul and the >> length, and I was thinking the new string functions would do likewise. sk> IMHO, it would be a very important part of the design that the sk> proposed "meme*" functions do not check for internal NULs. Certainly. That's the entire point behind the discussion we're having of str*() vs. mem*(). sk> example, modern interpreted languages allow for NULs in their sk> strings; this feature would help with the implementation. I don't know exactly what you mean by "modern interpreted languages", but in C the str*() family of functions always checks for the nul char, while the mem*() family never does. It goes without saying that any additions to those families would follow those conventions. -- ------------------------------------------------------------------------------- Paul D. Smith <psmith@xxxxxxx> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
