Re: String functions with end pointers?

[Paul Eggert]

"Paul D. Smith" <address@hidden> 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.