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

[Davi Arnaut]

On 10/1/10 1:07 PM, Alexey Kopytov wrote:
> On 01.10.10 17:57, Davi Arnaut wrote:
>> On 10/1/10 10:47 AM, Alexey Kopytov wrote:
>>
>> [..]
>>
>>>>
>>>> That HAVE_BZERO does not mean that we have the function prototype. In
>>>> other others, even thought cmake/autoconf might think bzero is
>>>> available, it might not actually be due to the lack of the
>>>> prototype. As
>>>
>>> OK, so HAVE_BZERO might be incorrectly defined on some platforms, which
>>> is obviously a bug. Its meaning is by definition (which is also assumed
>>> by the #ifdef in question): "there is a platform-defined bzero() that we
>>> can use".
>>
>> In autoconf, functions checks are implemented via link checks and I
>> assume cmake does the same. It's not exactly incorrectly defined, it
>> exists (and links successfully) but the prototype, which is required in
>> C++, is only present if the appropriate legacy defines are set.
>>
>
> So bzero() is not really available in C++ code on AIX. In this case we
> should not define HAVE_BZERO, that's it. We had a similar issue with
> isinf(), see bug #28240. Doesn't have anything to do with "legacy crap".

Yes, it has as it needs to be kept forever due to ABI compatibility. 
Again, you might interpret it this way but it does not change the _fact_ 
that the problem is because bzero is not included in the global 
namespace because it is legacy. This is done on purpose, bzero _is_ 
available (for compatibility reasons) but should _not_ be present by 
default in when compiling in a POSIX/ANSI environment.

>>>> for the other questions, they are just hand waving. We do not have
>>>> waste
>>>> time caring for legacy crap.
>>>>
>>>
>>> I did not claim the opposite. To make things dead simple, I say "we
>>> should not care about bzero()'s status, just do nothing. If it
>>> disappears, it will be mapped to memset() anyway".
>>
>> The point is that its not so simple. We a better off touching any legacy
>> stuff. There is nothing to gain from bzero expect trouble.
>>
>
> In my opinion, redefining bzero() on platforms where it is actually
> available is asking for troubles, too.

Indeed, but not the only trouble.

There is also the problem of it not having a standardized interface.

>>> And yes, incorrectly defined HAVE_BZERO is a different issue.
>>
>> Not exactly incorrect. That's the way autoconf/cmake works.
>>
>
> I am well aware how autoconf works. From the autoconf docs:
>
> "For each FUNCTION enumerated in the blank-or-newline-separated argument
> list, define `HAVE_FUNCTION' (in all capitals) if it is available."
>
> I think the only practically usable definition of "available" is "you
> can use it in your code". Since we can't really use bzero() in C++ code

autoconf obviously disagrees with you.

> on AIX, HAVE_BZERO is incorrectly defined. This is what should be fixed
> in bug #55721.

No. It is also not a problem particular to AIX.

I'm going to remove bzero completely once I have some time to spare. As 
I explained a few times already, we do not have to waste time fixing 
problems associated with legacy functions if there are perfectly fine 
replacements which are universally available.

Regards,

Davi