This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use strlen when searching for a nul char


Mike Frysinger wrote:
> this relies on _HAVE_STRING_ARCH_strchr & _HAVE_STRING_ARCH_rawmemchr
> being in sync in order for the strchr->strlen rewrite.  should we just
> do the strlen change in strchr itself too ?

If a target only defines _HAVE_STRING_ARCH_rawmemchr then presumably
it supports a fast rawmemchr, so it might be expected that strchr defers to rawmemchr
as it does today rather than using strlen.

If a target only defines _HAVE_STRING_ARCH_strchr then rawmemchr
would still use strlen, which is fine.

Wilco

>  #ifndef _HAVE_STRING_ARCH_strchr
>  extern void *__rawmemchr (const void *__s, int __c);
> -#  define strchr(s, c) \
> +# define strchr(s, c) \
>    (__extension__ (__builtin_constant_p (c) && !__builtin_constant_p (s)            \
>                 && (c) == '\0'                                              \
>                 ? (char *) __rawmemchr (s, c)                               \
>                 : __builtin_strchr (s, c)))
>  #endif
>
> +#ifndef _HAVE_STRING_ARCH_rawmemchr
> +extern void *__rawmemchr (const void *__s, int __c);
> +# define __rawmemchr(s, c) \
> +    (__extension__ ({ char *__s = (char *)(s);               \
> +      __builtin_constant_p (c) && (c) == '\0'                \
> +      ? (void *)(__s + strlen (__s))                 \
> +      : __rawmemchr (__s, (c));}))
> +# ifdef __USE_GNU
> +#  define rawmemchr(s,c) __rawmemchr ((s), (c))
> +# endif
> +#endif


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]