MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Paul DuBois Date:February 5 2008 4:19pm
Subject:Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535
View as plain text  
At 3:42 PM +0300 12/11/07, Konstantin Osipov wrote:
>* Sergei Golubchik <serg@stripped> [07/12/11 13:38]:
>
>>  > The header files are different, and it uses MY_INIT() rather
>>  > than my_init().  I seem to be using the same example for the
>>  > (now-in-progress) fourth edition.  Is the current code okay?
>>
>>  try to use mysql_library_init() instead of MY_INIT().
>>  And if load_defaults() will be in mysql.h then you won't need my_sys.h
>>  and my_global.h
>
>OK, I'd leave it to Paul.
>
>Paul, there are these alternatives now:
>
>  * I do nothing with this bug. Then the example in the third
>  * edition of your book stays valid and canonical.
>
>  * I push my patch. The canonical example will look like this:
>
>   #include <my_sys.h>
>   #include <mysql.h>
>   ... (same as before)
>
>   Rationale: load_defaults is not part of the client
>   library/connector but part of mysys (MySQL library for
>   system utilities and wrappers, which we happen to ship with the
>   connector). In effect this makes "officially" public other mysys
>   functions (free_defaults, modify_defaults_file). We do not
>   promise ABI compatibility for these, but we say they are there
>   and could be used.

It looks to me as though either of the first two alternatives will
require no changes to my example program, which has these #includes:

#include <my_global.h>
#include <my_sys.h>
#include <mysql.h>

Am I correct in thinking that?

>
>  * I follow Serg's suggestion. The example in your book will look
>    like
>
>   #include <mysql.h>
>
>   ... (same as before)
>
>   Rationale: load_defaults is an essential part of the client
>   library, that users should know about and be able to use.
>   We do not publicise the rest of mysys library.

So this would mean that I wouldn't need to include my_sys.h before
mysql.h? And could get away with not including it at all?

Question: With this third alternative, will programs still be *able*
to include my_sys.h before mysql.h? That is, suppose I try to compile
my example program using a MySQL distribution that incorporates this
third alternative.  Will it still compile, or will I need to change
something?

If it will still compile, it appears to me that all three
alternatives are compatible with the example program.  So in that
sense, I have no preference among the three.

 From an architectural standpoint, it would be good to choose the
alternative that will go farthest in the goal of better modularization
of the header files, I suppose. Which alternative is best for that,
or is this a question over which you and Serg disagree?


>
>Note, that the current example has a small memory leak: the
>memory used for load_defeaults is never freed (for that one has to
>use free_defaults). Since it is not a recurring leak it's not a
>problem, it will only be visible at exit, when running the program
>under valgrind.

Okay, thanks for pointing this out.

Is free_defaults() something that will always be in the same place
as load_defaults()?

>
>Serg, please correct me if I did not summarize the options correctly.
>
>--
>-- Konstantin Osipov              Software Developer, Moscow, Russia
>-- MySQL AB, www.mysql.com   The best DATABASE COMPANY in the GALAXY


-- 
Paul DuBois, MySQL Documentation Team
Madison, Wisconsin, USA
MySQL AB, www.mysql.com
Thread
bk commit into 5.1 tree (kostja:1.2614) BUG#25535konstantin4 Dec
  • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Sergei Golubchik6 Dec
    • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Konstantin Osipov6 Dec
      • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Sergei Golubchik7 Dec
        • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Konstantin Osipov7 Dec
          • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Paul DuBois7 Dec
            • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Konstantin Osipov7 Dec
          • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Sergei Golubchik7 Dec
            • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Konstantin Osipov7 Dec
              • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Sergei Golubchik7 Dec
                • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Konstantin Osipov7 Dec
                  • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Sergei Golubchik11 Dec
                • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Konstantin Osipov7 Dec
                  • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Sergei Golubchik11 Dec
                    • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Paul DuBois11 Dec
                • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Konstantin Osipov8 Dec
                  • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Paul DuBois8 Dec
                    • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Konstantin Osipov8 Dec
                    • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Sergei Golubchik11 Dec
                      • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Konstantin Osipov11 Dec
                        • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Sergei Golubchik11 Dec
                        • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Paul DuBois5 Feb
                      • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Paul DuBois11 Dec
                        • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Paul DuBois11 Dec
                          • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Sergei Golubchik11 Dec
                            • Re: bk commit into 5.1 tree (kostja:1.2614) BUG#25535Paul DuBois11 Dec