Re: bzr commit into mysql-5.1-bugteam branch (Alexey.Kopytov:3514) Bug#56709

[Alexey Kopytov]

(resending with correct To/CC)

On 01.10.10 17:16, Tor Didriksen wrote:
> On Fri, Oct 1, 2010 at 1:24 PM, Alexey
> Kopytov<Alexey.Kopytov@stripped>wrote:
>
>> On 01.10.10 12:04, Tor Didriksen wrote:
>>
>>> On Thu, Sep 30, 2010 at 2:36 PM, Sergei Golubchik<serg@stripped>
>>>   wrote:
>>>
>>>   Hi, Davi!
>>>>
>>>> On Sep 30, Davi Arnaut wrote:
>>>>
>>>>> On 9/30/10 8:33 AM, Tor Didriksen wrote:
>>>>>
>>>>>> On Fri, Sep 24, 2010 at 11:20 AM, Alexey Kopytov
>>>>>>
>>>>>>>
>>>>>>>>   I personally think of bzero() as a convenient alias for
> the most
>>>>>>>>   commonly used form of memset(). In other words, even if
> bzero()
>>>>>>>>   did not exist, it should have been created. And we
> actually do
>>>>>>>>   something like that in m_string.h:
>>>>>>>>
>>>>>>>>   #if !defined(bzero)&&    !defined(HAVE_BZERO)
>>>>>>>>   # define bzero(A,B)             memset((A),0,(B))
>>>>>>>>   #endif
>>>>>>>>
>>>>>>>
>>>>>> Time for another update of the style guide I guess,
>>>>>> we shouldn't be recommending functions which are deprecated.
>>>>>>
>>>>>
>>>>> Definitely. bzero is a officially deprecated function and we never
>>>>> actually use it because it depends on some BSD defines that we never
>>>>> set.
>>>>>
>>>>
>>>> So, Kaamos is right after all :)
>>>>
>>>> Coding style does not recommend a deprecated function, furthermore this
>>>> deprecated function was never used. bzero() is just a convenience macro,
>>>> and should be fine as such. The fact that libc has deprecated a function
>>>> does not apply to MySQL internal macro that happen to have the same
>>>> name :)
>>>>
>>>>
>>> no ??
>>>
>>> #if !defined(bzero)&&   !defined(HAVE_BZERO)
>>> # define bzero(A,B)             memset((A),0,(B))
>>> #endif
>>>
>>> configure/cmake will define HAVE_BZERO
>>> and we end up calling the deprecated function in the C library
>>>
>>> -- didrik
>>>
>>>
>> Yes, we do use bzero(), at least on Linux, Solaris and Mac OS X, since we
>> include both string.h (which defines bzero() only when __USE_BSD is defined)
>> and strings.h (which seems to define bzero() on complementary to __USE_BSD
>> conditions).
>>
>> But then again,
>> http://www.opengroup.org/onlinepubs/000095399/functions/bzero.html :
>>
>> "For maximum portability, it is recommended to replace the function call to
>> bzero() as follows:
>>
>> #define bzero(b,len) (memset((b), '\0', (len)), (void) 0)
>> "
>>
>> Which is what we do in m_string.h when bzero() is unavailable. "For maximum
>> portability". Does that mean we comply with POSIX? Or, why should we care
>> about the legacy status of bzero() at all?
>>
>> /Alexey.
>>
>
> bzero does not seem to be well defined, I'm getting this during MySQL
> configure on Fedora release 12
> config.log:conftest.c:247: warning: conflicting types for built-in function
> 'bzero'
>

"built-in", are you sure this particular warning has anything to do with 
bzero()'s status in posix?

> on some platforms it is not defined

Right, so we map it to memset() when it's not defined.

> on some platforms it is available, but in non-standard places

Yes, just like lots of other functions, constants and types we use. 
my_global.h is probably the best proof.

> it was deprecated by posix 9 years ago
> it is not part of the current posix standard
>

Does this mean we should not use it on platforms where it is available? 
Does this mean we should not use a macro by the same name, if it's not?

/Alexey.

> -- didrik
>