[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: String functions with end pointers?

From: Bernd Jendrissek
Subject: Re: String functions with end pointers?
Date: Wed, 26 Apr 2006 17:48:07 +0200
User-agent: Mutt/

Hash: SHA1

On Tue, Apr 25, 2006 at 06:17:21PM -0400, Paul D. Smith wrote:
> %% Paul Eggert <address@hidden> writes:
>   pe> Paul Eggert <address@hidden> writes:
>   pe> char *memechr(const char *str, const char *endp, char c);
              ^^^                 ^^^
>   pe> Come to think of it, this kind of signature isn't right for the mem*
>   pe> family, and I suppose it should be something like this instead:
>   pe> void *memechr(const void *mem, const void *endp, unsigned char c);
>  void *memechr(const void *mem, const void *endp, uint8_t c);
> !!
> :-)

No, wrong function - that signature belongs to memeuint8. :-)  memechr's
@param c should probably be whatever type character are; that's the
neuter/hermaphroditic 'char' isn't it?

BTW, remember that the entire str* namespace is reserved for the C
implementation.  It might #define str * // and you'd struggle to figure
out why you get warnings about different levels of indirection in client
code.  (Bad idea to use parameter names in prototypes, but I do it too.)
I wouldn't be surprized if mem* is reserved too.


Speaking of reserved namespaces, what is the favourite constant to
AC_DEFINE inside AC_ENABLE_ARG?  I've taken to ENABLE_FOO, but
apparently all of E* is reserved for errors.

#define EPIPE            32   /* Broken pipe */
#define ECRAY           198   /* Program exited before being run */
#define ENABLE_SHNUR    199   /* Broken umbilical cord */

- -- 
Problems experienced downstream are symptoms of neglect upstream.
Upstream problems can only be solved upstream. - Ad Sparrius
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Please fetch my new key 804177F8 from hkp://


reply via email to

[Prev in Thread] Current Thread [Next in Thread]