[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: String functions with end pointers?
From: |
Paul D. Smith |
Subject: |
Re: String functions with end pointers? |
Date: |
25 Apr 2006 08:51:48 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 |
%% 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