Re: String functions with end pointers?

[Paul D. Smith]

%% Paul Eggert <address@hidden> writes:

  pe> "Paul D. Smith" <address@hidden> writes:
  >> Are there any such functions in GLIB or similar?  Do people know of
  >> similar functions in other OS's etc.?  If not, and I wanted to think
  >> about creating some, what kind of naming convention would be
  >> appropriate?  I thought of strp*() but I don't know.

  pe> I don't know of any such functions, though they sound like nice ones
  pe> to have.

  pe> I wouldn't use strp*, since that prefix is already used for strpbrk
  pe> and strptime, not to mention glibc strpcpy.  Nor strl*, since it's
  pe> used for OpenBSD strlcpy and strlcat
  pe> <http://en.wikipedia.org/wiki/Strlcpy>.  Nor stre*, since it's used
  pe> for Plan 9 strecpy
  pe> <http://plan9.bell-labs.com/sources/plan9/sys/src/libc/port/strecpy.c>.

  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.

But, on second thought, I don't know that I need this.  If I have a
pointer to the end I'm pretty sure it's always on or before the nul
char.

  pe> How about "meme*", for "memory with end pointer"?  (I think the "e" in
  pe> Plan 9 "strecpy" also means "end pointer".)  E.g.,

How frustrating that the arguments in strecpy() don't follow convention;
the end pointer should be (IMO) the last argument, just like the length
is the last argument in strncpy().

  pe> char *memechr(const char *str, const char *endp, int c);

Ditto here: why is the endp the second argument when in memcpy(),
memchr(), etc. the length is the last argument?

I would rather see:

    char *memechr(const char *str, char c, const char *endp);

  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?

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