| List: | Commits | « Previous MessageNext Message » | |
| From: | Davi Arnaut | Date: | October 1 2010 1:28pm |
| Subject: | Re: bzr commit into mysql-5.1-bugteam branch (Alexey.Kopytov:3514) Bug#56709 | ||
| View as plain text | |||
On 10/1/10 9:38 AM, Alexey Kopytov wrote: > On 01.10.10 16:02, Davi Arnaut wrote: >> On 10/1/10 8:24 AM, Alexey Kopytov 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? >>> >> >> Take some time to read Bug#55721 and look at the condition again. > > I did and I have two questions: > > 1. To which specific statement or question were you replying? "Which is what we do in m_string.h when bzero() is unavailable." > 2. What exactly did you want to tell me by pointing to the bug and > asking to look at the condition again? 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 for the other questions, they are just hand waving. We do not have waste time caring for legacy crap. Regards, Davi
