Re: [PATCH] compat: add memrchr()

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

 



On Fri, Oct 15, 2010 at 06:06, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Ãvar ArnfjÃrà Bjarmason wrote:
>
>> Maybe something like this for configure.ac:
>>
>> Â Â AC_CHECK_LIB([c], [memchr],
>> Â Â [HAVE_MEMRCHR=YesPlease],
>> Â Â [HAVE_MEMRCHR=])
>> Â Â AC_SUBST(HAVE_MEMRCHR)
>>
>> And documentation with the other HAVE_* variables at the top of the
>> Makefile?
>
> Hmm, the BSDs and plan 9 have an memrchr() apparently. Â Any idea for
> taking advantage of that (the makefile support part) that's less ugly
> than this?

Check out my "Makefile & configure: add a NO_FNMATCH flag" and
"Makefile & configure: add a NO_FNMATCH_CASEFOLD flag" patches already
in pu.

Maybe it should be a NO_* flag since that's what we use when we expect
sanity, e.g. we have NO_REGEXP=, NO_CURL and NO_GETTEXT.

Then you just need NO_MEMRCHR=UnfortunatelyYes entries in the big
if/else block for those platforms that don't have it.

But memrchr() is a GNU extension so it should probably be a HAVE_*. I
don't know.

> If we miss a platform, that's no big deal. ÂThe 1-char-at-a-time
> loop is not so slow, and the "#define memrchr gitmemrchr" ensures
> that it would not conflict with the libc version.

Yup, probably best as a HAVE_*. In any case the autoconf probe I added
should work when memrchr is spelled properly.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]