This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: Passing 0 for number of bytes to be scanned in memchr


> If __s is a null pointer then passing it to memchr is undefined.

That means we are missing the check when __s == nullptr?
I also wanted to know what happens when __n is zero in the case of memchr. I think memchr returns null in this case so we can remove that check.

Thanks,
-Aditya




From: Jonathan Wakely <jwakely@redhat.com>
Sent: Thursday, February 16, 2017 6:12 AM
To: Aditya K
Cc: libstdc++@gcc.gnu.org
Subject: Re: Passing 0 for number of bytes to be scanned in memchr
    
On 16/02/17 11:38 +0000, Aditya K wrote:
>Hi Jonathan,
>
>I see that in char_traits<char>::find, we check if the number of bytes to be scanned is zero. I think memchr handles that case already but I do not have
>
>any reference to point out to. The documentation does not explicitly mention what happens when 'n' is zero. If n==0 is already handled then
>
>we can safely remove this check. Please let me know your thoughts.
>
>
>269       static const char_type*
>270       find(const char_type* __s, size_t __n, const char_type& __a)
>271       {
>272         if (__n == 0)
>273           return 0;
>274         return static_cast<const char_type*>(__builtin_memchr(__s, __a, __n));
>275       }

If __s is a null pointer then passing it to memchr is undefined.

I'm not 100% sure, but I don't think basic_string::find has the same
restriction, so we need to handle the case where it's null and avoid
calling memchr.


    

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