"Paul D. Smith" <psmith@xxxxxxx> writes: > the end pointer should be (IMO) the last argument, just like the length > is the last argument in strncpy(). I suspect their design criterion was to put the start and end pointers next to each other in the argument list, since these two C arguments describe the same piece of storage. The situation with strncpy(DEST,SRC,N) is different, since N describes the length of SRC, not of DEST. The usual tradition (e.g., fgets, strncpy, snprintf) is to put the buffer pointer and length next to each other. If you want to replace the length with a buffer-end pointer, I would think that you would stick with the same tradition, and keep the buffer-start next to the buffer-end in the argument list. > pe> And while you're at it, why not fix the type of the last arg, since > pe> you're not assuming K&R compatibility any more? > > pe> char *memechr(const char *str, const char *endp, char c); > > OK... remind me (very briefly) again why it was "int c" before? > Something to do with promotion rules... if you didn't have a prototype > in scope (and there were no prototypes in K&R of course) was it? Yes, that's right. In K&R C, a char argument was actually passed as if it were an int, and if you wanted K&R code to interoperate with C89 code you had to use a prototype that said 'int' and not 'char'. These concerns are now obsolete. Nowadays the only realy reason you'd want memechr to take an int argument is to avoid answering questions from people who don't understand the history behind strchr's interface. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
