libdbi-devel — Discussion about development of the core library and DBD interface

Re: [libdbi-devel] Library version macro

[Markus H. <mar...@mh...>]

Hi,

Andreas Ericsson writes:
 > If you add functions to the library, it will remain LINK compatible
 > with applications compiled against older versions of the library (so
 > the ABI-version must not be changed), but programmers who wish to utilize

I don't understand libtool's interface definition this way:

http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning

Unless I'm dense, the ABI version, i.e. LIB_CURRENT does change if you
add functions to the library. However, if you do it in a way that
allows apps programmed against an older version of the interface to
still work properly, LIB_AGE gets bumped up accordingly.

 > No it's not. It depends on how rigid your various version
 > numbers are. For example, a change from 0.8.3 to 1.0 means all bets
 > are off. Every function in the library could have a new name, or a
 > different call signature or whatever. If you bump it from 0.8.3 to
 > 0.8.4, you mustn't alter existing parts of the library but can only
 > fix bugs that modify existing parts in a link-compatible way.
 > 0.8.3 to 0.9.0 means you can add new functions (introducing a new
 > .so-version that older applications can link against, but apps built
 > against that version of the library cannot necessarily be linked to
 > older versions of the library).
 > 

First of all, I suggest to move to 1.0 (=1:0:0) because our library
version information has been broken since 0.6 (in fact, the stuff has
been broken from the very beginning as the maintainers back then
arbitrarily started at 0:5:0 instead of 0:0:0). We eventually have to
get this straight, and the changes implemented in the upcoming
release, like instances, provide a good occasion to do so. This is
admittedly a bit unclean, but further building upon the incorrect
interface numbers is probably not going to do us any good.

Now for your discussion of the version numbers. I see this as a pretty
arbitrary convention to use the second position to denote interface
changes (what is the first position good for?). If you replace 0.8.3
with 8.3, 0.8.4 with 8.4, and 0.9.0 with 9.0 in your above discussion,
all your points still hold true, but the shorter numbers could easily
be derived from libtool's interface version numbers.


 > > What changes would justify increasing  
 > > LIBDBI_MAJOR without affecting LIBDBI_LIB_CURRENT?
 > 
 > None. But you could go from 0.8.0 to 0.8.1 without bumping the .so-
 > version if you make some simple bugfixes without adding new functionality
 > in 0.8.1.
 > 

Just as I could go from 8.0 to 8.1 (LIB_CURRENT doesn't change,
LIB_REVISION gets bumped) without affecting the .so number.

 > If by "new interface" you mean adding functionality without touching old
 > stuff in the library, it's because old applications can still run with
 > the new library if you only bump the API version.
 > 

And they can do so if I bump both LIB_CURRENT and LIB_AGE, unless I'm
way off.

 > > Also, a library isn't something  
 > > that needs to be marketed via version numbers. We'll never jump from  
 > > 1.2 to 5.0 just because some competitor has 4.0.
 > > 
 > 
 > It's not about that, and all about being able to add new functionality
 > without forcing old applications to be rebuilt against the new API *if*
 > you didn't change the old one.
 > 

Sure. I just wanted to make my point that library version numbers
need not be arbitrary numbers. It doesn't hurt if they simply reflect
the ABI changes.

 > (why is LIBDBI_LIB_AGE bumped here?)
 > 
 > bzzt! wrong. Now every app linked against an old library will have to be
 > relinked against the new one. A major headache for package maintainers.
 > 
No, because we've bumped LIB_AGE.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] Library version macro

[Florian F. <oc...@ve...>]

Hi again,

On Tue, Mar 17, 2009 at 05:09:15PM +0100, Markus Hoenicka wrote:
> I'm not going to do that, as discussed before on this list. In brief,
> we forgot to update the libtool interface version info in the past. In
> the worst case your suggestion will cause us to forget to uptate the
> interface version *and* the library version :-(

updating the ABI version is basically not possible to do automatically,
that's true. Updating the defines suggested automatically would be easy,
though:
-- 8< (configure.{ac,in}) --
 LIBDBI_VERSION_MAJOR=`echo $PACKAGE_VERSION | cut -d'.' -f1`
 LIBDBI_VERSION_MINOR=`echo $PACKAGE_VERSION | cut -d'.' -f2`
 LIBDBI_VERSION_PATCH=`echo $PACKAGE_VERSION | cut -d'.' -f3`
 AC_SUBST(LIBDBI_VERSION_MAJOR)
 AC_SUBST(LIBDBI_VERSION_MINOR)
 AC_SUBST(LIBDBI_VERSION_PATCH)
-- >8 --

-- 8< (dbi_version.h.in) --
 #define LIBDBI_VERSION_MAJOR @LIBDBI_VERSION_MAJOR@
 #define LIBDBI_VERSION_MINOR @LIBDBI_VERSION_MINOR@
 #define LIBDBI_VERSION_PATCH @LIBDBI_VERSION_PATCH@
 #define LIBDBI_VERSION_STRING "@LIBDBI_VERSION_MAJOR@." \
           "@LIBDBI_VERSION_MINOR@.@LIBDBI_VERSION_PATCH@"
-- >8 --

> But  instead of abusing the library version as an interface version,
> I'd  like to use the interface version as the library version.

Yeah, that should work, too..

> I've never  understood why a library needs a version number that is
> different from the interface number.

Well, I usually think of the API as being whatever is *documented*. For
example, changing the order of members in a struct would, in my opinion,
not break API compatibility but would break ABI compatibility. As a
developer, i. e. an ``API user'', this would not be of importance to me.
Or course, this is a trivial example. I'm sure you can think of some
more practical examples, a bitfield being widened or a struct being
changed but the API only documents macros to access the struct or
something.

Personally, I like the package version to make a statement towards API
compatibility, because I mainly use libraries from the viewpoint of a
developer. The system I'm usually using is the following:
- The major version increases upon backwards-incompatible API changes.
- The minor version increases upon backwards-compatible API changes,
  usually additions.
- The patch version is increased if the API has not been changed at all.

The ``major'' number of this schema would roughly equal `current - age'.

> What changes would justify increasing  LIBDBI_MAJOR without affecting
> LIBDBI_LIB_CURRENT?

If you use `current' as major version, it is increased whenever anything
in the API changes (assuming you don't start doing extensive
preprocessor trickery to keep the functions as they are ;) - whether
backwards compatible or not. So my point is the other way around: The
`current' version must be increased when I would keep the `major'
version as is.

> Why would changes  that require a new interface be reflected by an
> increase of  LIBDBI_MINOR instead of LIBDBI_MAJOR?

In the schema above: When a function is *added*. In that case:
- current would be increased.
- revision would be reset to zero.
- age would be increased.

- major would stay the same.
- minor would be increased.
- patch would be reset to zero.

> Would that cause any grief?

No, it'd be fine by me. Please don't get me wrong, I'm not trying to
convince you. You asked, so I felt inclined to explain the schema that
has worked very well for me in more detail.. ;)

Maybe a define such as
 #define LIBDBI_API_MAJOR (LIBDBI_MAJOR - LIBDBI_AGE)
would be nice to have though ;)

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/

Re: [libdbi-devel] Library version macro

[Peter O'G. <pe...@po...>]

Andreas Ericsson wrote:

>> So, to sum it up:
>>
>> Next release, called "1.0":
>> LIBDBI_LIB_CURRENT 1
>> LIBDBI_LIB_REVISION 0
>> LIBDBI_LIB_AGE 1
>>
>> If we fix some bugs in that release, we'll have "1.1":
>>
>> LIBDBI_LIB_CURRENT 1
>> LIBDBI_LIB_REVISION 1
>> LIBDBI_LIB_AGE 1
>>
>> If we add further functions in a backwards compatible way, we'll have "2.0":
>>
>> LIBDBI_LIB_CURRENT 2
>> LIBDBI_LIB_REVISION 0
>> LIBDBI_LIB_AGE 2
>>
> 
> (why is LIBDBI_LIB_AGE bumped here?)

So the soname doesn't change.

Peter
--
Peter O'Gorman
http://pogma.com

Re: [libdbi-devel] Library version macro

[Andreas E. <ae...@op...>]

Markus Hoenicka wrote:
> 
> Quoting Florian Forster <oc...@ve...>:
> 
> 
>> By all means, introduce version testing macros/defines, such as:
>>  #define LIBDBI_MAJOR 0
>>  #define LIBDBI_MINOR 8
>>  #define LIBDBI_PATCH 3
> 
> I'm not going to do that, as discussed before on this list. In brief,  
> we forgot to update the libtool interface version info in the past. In  
> the worst case your suggestion will cause us to forget to uptate the  
> interface version *and* the library version :-(
> 

Ah, I see the problem now. You're doing this the wrong way around. The
API version mustn't be dictated by the ABI version, but it's just fine
to do it the other way around (openssl does that, fe).

The reason is this;
If you add functions to the library, it will remain LINK compatible
with applications compiled against older versions of the library (so
the ABI-version must not be changed), but programmers who wish to utilize
those new functions can't do so because they'll have no way of knowing
what API they're programming against.

>>  #define LIBDBI_VERSION ((1000000 * LIBDBI_MAJOR) \
>>  	                +   (1000 * LIBDBI_MINOR) \
>> 			+           LIBDBI_PATCH)
>>
> 
> I'll be happy to do something along these lines, based on the version  
> numbers that we have.
> 
>> But mis-using the ABI version numbers for this purpose is evil, Evil,
>> EVIL!
>>
> 
> Not quite. The warning in the libtool manual about not forcing the  
> library version into the interface version is absolutely correct.

No it's not. It depends on how rigid your various version
numbers are. For example, a change from 0.8.3 to 1.0 means all bets
are off. Every function in the library could have a new name, or a
different call signature or whatever. If you bump it from 0.8.3 to
0.8.4, you mustn't alter existing parts of the library but can only
fix bugs that modify existing parts in a link-compatible way.
0.8.3 to 0.9.0 means you can add new functions (introducing a new
.so-version that older applications can link against, but apps built
against that version of the library cannot necessarily be linked to
older versions of the library).

Note that you can get around this by explicitly versioning symbols
of the same name but with different call signatures (glibc does this,
and it's why programs compiled against 3.3.6 work just fine against
3.2.0 of the library, assuming they aren't using functions introduced
after 3.2.0).

> But  
> instead of abusing the library version as an interface version, I'd  
> like to use the interface version as the library version.

That's what's entirely evil.

> I've never  
> understood why a library needs a version number that is different from  
> the interface number.

It doesn't, but you need to let the library version set the ABI version
in that case, in the way I explained above.

> What changes would justify increasing  
> LIBDBI_MAJOR without affecting LIBDBI_LIB_CURRENT?

None. But you could go from 0.8.0 to 0.8.1 without bumping the .so-
version if you make some simple bugfixes without adding new functionality
in 0.8.1.

> Why would changes  
> that require a new interface be reflected by an increase of  
> LIBDBI_MINOR instead of LIBDBI_MAJOR?

If by "new interface" you mean adding functionality without touching old
stuff in the library, it's because old applications can still run with
the new library if you only bump the API version.

> Also, a library isn't something  
> that needs to be marketed via version numbers. We'll never jump from  
> 1.2 to 5.0 just because some competitor has 4.0.
> 

It's not about that, and all about being able to add new functionality
without forcing old applications to be rebuilt against the new API *if*
you didn't change the old one.

> So, to sum it up:
> 
> Next release, called "1.0":
> LIBDBI_LIB_CURRENT 1
> LIBDBI_LIB_REVISION 0
> LIBDBI_LIB_AGE 1
> 
> If we fix some bugs in that release, we'll have "1.1":
> 
> LIBDBI_LIB_CURRENT 1
> LIBDBI_LIB_REVISION 1
> LIBDBI_LIB_AGE 1
> 
> If we add further functions in a backwards compatible way, we'll have "2.0":
> 
> LIBDBI_LIB_CURRENT 2
> LIBDBI_LIB_REVISION 0
> LIBDBI_LIB_AGE 2
> 

(why is LIBDBI_LIB_AGE bumped here?)

bzzt! wrong. Now every app linked against an old library will have to be
relinked against the new one. A major headache for package maintainers.

If you *CHANGE* parts of the API, it will be 2.0 because old apps will
break down horribly if you try to run them using the changed API (with
random stack frame corruption; Those issues can drive you mad and want
to shoot the poor library developers who didn't realize why changing
unsigned long to socklen_t in an exposed function in the library sucks
tremenduously for 64-bit users).

This is the reason most libraries have 3 version numbers.
A.B.C:
A is bumped when the library is re-designed so that no old application
works without at least being relinked.
B is bumped when new functionality is added.
C is bumped when innocuous bugfixes that do not in any way what so ever
alter how the ABI works are done.

A and B usually make up the .so-version (openssl are a bit freakish as
they use 0.A.BX, where X is always a letter, but they're the only major
library to not use the 3-number scheme that I know of).

Note that the programmer needs to know about the version of C in the
compiled library as well, since he/she may well have to work around
known bugs manually in case his/her program happens to run on a library
of the old version while being compiled against a newer one. This is
why most libraries have "libfoo_version()" return an unsigned long
formatted the same way as the LIBFOO_VERSION macro.

> All of this accessible to the compiler via:
> 
> #define LIBDBI_VERSION ((1000 * LIBDBI_LIB_CURRENT) \
> 			+           LIBDBI_LIB_REVISION)
> 
> And, all updates to these numbers done in one place in configure.in.
> 
> Would that cause any grief?
> 

Possibly not, but possibly extraordinary amounts of it. I'm sure you
can see why now.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [libdbi-devel] Library version macro

[Markus H. <mar...@mh...>]

Quoting Andreas Ericsson <ae...@op...>:

>> Why not just use pkg-config and install a .pc file? Or am I missing
>> something?
>>
>
> What you're missing is that no compiler in the world will ever look at
> a .pc file, and the information should be available inside the library
> headers to be of any use.
>

Besides, we seem to have a .pc file. However, I still have to figure  
out how to use it :-(

regards,
Markus


-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] Library version macro

[Andreas E. <ae...@op...>]

Peter O'Gorman wrote:
> Markus Hoenicka wrote:
>> Hi there,
> 
>>>  #define LIBDBI_VERSION ((1000000 * LIBDBI_MAJOR) \
>>>  	                +   (1000 * LIBDBI_MINOR) \
>>> 			+           LIBDBI_PATCH)
>>>
>> I'll be happy to do something along these lines, based on the version  
>> numbers that we have.
>>
> 
> Why not just use pkg-config and install a .pc file? Or am I missing
> something?
> 

What you're missing is that no compiler in the world will ever look at
a .pc file, and the information should be available inside the library
headers to be of any use.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [libdbi-devel] Library version macro

[Peter O'G. <pe...@po...>]

Markus Hoenicka wrote:
> Hi there,

>>  #define LIBDBI_VERSION ((1000000 * LIBDBI_MAJOR) \
>>  	                +   (1000 * LIBDBI_MINOR) \
>> 			+           LIBDBI_PATCH)
>>
> 
> I'll be happy to do something along these lines, based on the version  
> numbers that we have.
> 

Why not just use pkg-config and install a .pc file? Or am I missing
something?

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: [libdbi-devel] Library version macro

[Markus H. <mar...@mh...>]

Hi there,

Quoting Florian Forster <oc...@ve...>:

> I think you're making the (common) mistake to confuse API and ABI
> versions. It is not useful for a C program (or its compiler) to know the
> ABI version. It's used by the linker to figure out if an installed
> version of the library is compatible with the library used when
> compiling and linking the program, i. e. when it is (about to be) run.
>
> The API version *is* useful for the C program and its compiler to know,
> so it knows which features are available. In contrast to the ABI
> version, this information is used at compile time.
>

I'm aware of this distinction, although it doesn't hurt to think about  
it once in a while.

> By all means, introduce version testing macros/defines, such as:
>  #define LIBDBI_MAJOR 0
>  #define LIBDBI_MINOR 8
>  #define LIBDBI_PATCH 3

I'm not going to do that, as discussed before on this list. In brief,  
we forgot to update the libtool interface version info in the past. In  
the worst case your suggestion will cause us to forget to uptate the  
interface version *and* the library version :-(

>  #define LIBDBI_VERSION ((1000000 * LIBDBI_MAJOR) \
>  	                +   (1000 * LIBDBI_MINOR) \
> 			+           LIBDBI_PATCH)
>

I'll be happy to do something along these lines, based on the version  
numbers that we have.

>
> But mis-using the ABI version numbers for this purpose is evil, Evil,
> EVIL!
>

Not quite. The warning in the libtool manual about not forcing the  
library version into the interface version is absolutely correct. But  
instead of abusing the library version as an interface version, I'd  
like to use the interface version as the library version. I've never  
understood why a library needs a version number that is different from  
the interface number. What changes would justify increasing  
LIBDBI_MAJOR without affecting LIBDBI_LIB_CURRENT? Why would changes  
that require a new interface be reflected by an increase of  
LIBDBI_MINOR instead of LIBDBI_MAJOR? Also, a library isn't something  
that needs to be marketed via version numbers. We'll never jump from  
1.2 to 5.0 just because some competitor has 4.0.

So, to sum it up:

Next release, called "1.0":
LIBDBI_LIB_CURRENT 1
LIBDBI_LIB_REVISION 0
LIBDBI_LIB_AGE 1

If we fix some bugs in that release, we'll have "1.1":

LIBDBI_LIB_CURRENT 1
LIBDBI_LIB_REVISION 1
LIBDBI_LIB_AGE 1

If we add further functions in a backwards compatible way, we'll have "2.0":

LIBDBI_LIB_CURRENT 2
LIBDBI_LIB_REVISION 0
LIBDBI_LIB_AGE 2

All of this accessible to the compiler via:

#define LIBDBI_VERSION ((1000 * LIBDBI_LIB_CURRENT) \
			+           LIBDBI_LIB_REVISION)

And, all updates to these numbers done in one place in configure.in.

Would that cause any grief?

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] Library version macro

[Florian F. <oc...@ve...>]

Hi,

On Tue, Mar 17, 2009 at 03:13:53PM +0100, Markus Hoenicka wrote:
> They do, but in a reasonable way. LIB_CURRENT is the API version
> number proper. LIB_REVISION numbers the revisions that do not change
> the API (what you call "micro-releases"). LIB_AGE indicates how many
> version numbers the current release is backwards-compatible with.

I think you're making the (common) mistake to confuse API and ABI
versions. It is not useful for a C program (or its compiler) to know the
ABI version. It's used by the linker to figure out if an installed
version of the library is compatible with the library used when
compiling and linking the program, i. e. when it is (about to be) run.

The API version *is* useful for the C program and its compiler to know,
so it knows which features are available. In contrast to the ABI
version, this information is used at compile time.

By all means, introduce version testing macros/defines, such as:
 #define LIBDBI_MAJOR 0
 #define LIBDBI_MINOR 8
 #define LIBDBI_PATCH 3
 #define LIBDBI_VERSION ((1000000 * LIBDBI_MAJOR) \
 	                +   (1000 * LIBDBI_MINOR) \
			+           LIBDBI_PATCH)

Andreas' code could then do something like:
 #if defined(LIBDBI_VERSION) && (LIBDBI_VERSION >= 8003)
 use_new_feature ();
 #else
 use_own_implementation ();
 #endif

But mis-using the ABI version numbers for this purpose is evil, Evil,
EVIL!

Unfortunately I don't have a good link at hand which explains the issue
in detail, so I'll have to back up my claims with the last paragraph on
this page of the libtool manual:
<http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html>

Hope this clears things up and I especially hope I didn't misunderstand
you all along and told you something you already were aware of ;)

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/

Re: [libdbi-devel] Library version macro

[Andreas E. <ae...@op...>]

Florian Forster wrote:
> Hi,
> 
> On Tue, Mar 17, 2009 at 03:13:53PM +0100, Markus Hoenicka wrote:
>> They do, but in a reasonable way. LIB_CURRENT is the API version
>> number proper. LIB_REVISION numbers the revisions that do not change
>> the API (what you call "micro-releases"). LIB_AGE indicates how many
>> version numbers the current release is backwards-compatible with.
> 
> I think you're making the (common) mistake to confuse API and ABI
> versions. It is not useful for a C program (or its compiler) to know the
> ABI version. It's used by the linker to figure out if an installed
> version of the library is compatible with the library used when
> compiling and linking the program, i. e. when it is (about to be) run.
> 
> The API version *is* useful for the C program and its compiler to know,
> so it knows which features are available. In contrast to the ABI
> version, this information is used at compile time.
> 
> By all means, introduce version testing macros/defines, such as:
>  #define LIBDBI_MAJOR 0
>  #define LIBDBI_MINOR 8
>  #define LIBDBI_PATCH 3
>  #define LIBDBI_VERSION ((1000000 * LIBDBI_MAJOR) \
>  	                +   (1000 * LIBDBI_MINOR) \
> 			+           LIBDBI_PATCH)
> 
> Andreas' code could then do something like:
>  #if defined(LIBDBI_VERSION) && (LIBDBI_VERSION >= 8003)
>  use_new_feature ();
>  #else
>  use_own_implementation ();
>  #endif
> 

That's exactly what I'm talking about :)

> But mis-using the ABI version numbers for this purpose is evil, Evil,
> EVIL!
> 

Indeed.

> Unfortunately I don't have a good link at hand which explains the issue
> in detail, so I'll have to back up my claims with the last paragraph on
> this page of the libtool manual:
> <http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html>
> 

http://people.redhat.com/drepper/dsohowto.pdf has some more info.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [libdbi-devel] Library version macro

[Markus H. <mar...@mh...>]

Quoting Andreas Ericsson <ae...@op...>:

>> LIB_{CURRENT,REVISION,AGE} for quite a while.
>
> But aren't those determining the .so-version as well? If so, it wouldn't
> be correct to update them with micro-releases, since the linker would
> believe a later version is incompatible with an earlier one.
>

They do, but in a reasonable way. LIB_CURRENT is the API version  
number proper. LIB_REVISION numbers the revisions that do not change  
the API (what you call "micro-releases"). LIB_AGE indicates how many  
version numbers the current release is backwards-compatible with. The  
runtime linker is able to figure out everything from these three  
numbers. For example, bugfixes bump up LIB_REVISION without affecting  
the other numbers. Your linker will be happy to run any of your  
programs with this bug-fixed version. If we add functions though,  
LIB_CURRENT gets bumped up, and your linker will refuse to run your  
programs unless LIB_AGE permits to do so.

> The best trick is probably to utilize the vcs versioning numbers and
> use a script to cut releases. Sadly, I have no idea how to make that
> work in cvs, although I could do it blindfolded in git, hint hint ;-)
>

This might work in svn, but not in cvs, as the latter uses revision  
numbers for individual files rather than for repositories. A critical  
change in one of the files would not be reflected in the version  
number of another file which is used to number the releases.

> Sounds awesome, but I'd still invite you to give some serious thought
> to having it be updated automagically when you cut a release. Any manual
> labour is bound to go stale sooner or later.
>

We've had this discussion in the past. I'm pretty sure the current way  
of dealing with versioning does involve the minimum amount of work  
possible. It is of course tempting to use VCS revision numbers for  
versioning, but in order to avoid runtime linker problems we have to  
update the LIB_XYZ constants anyway. configure.in is set up to promote  
this information to dbi.h automatically, so there is no further manual  
work required. As a side effect we have to deal only with one set of  
numbers.

>> For the time being you'd have to write configure tests which look   
>> for the functions that you want to call. For libdbi releases up to   
>> 0.8.3 this is the only reliable way to test for the presence of   
>> these functions. Let me know if you need further assistance.
>>
>
> Ugh. That's more complexity than it's worth. I've just hacked around it
> using a wrapper for dbi_conn_quote_string_copy() atm. It suffices for
> my needs. Thanks for the tip though. I'll look into it if I run into
> anything I can't work around in some other way.
>

Hey, I know it's cumbersome, but it is not that hard. All you need to  
do is to write a three-line app which calls the desired function.  
autoconf has macros to detect whether linking this app is going to  
work. Just let me know if there is a problem that you can't "wrap"  
around.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] Library version macro

[Andreas E. <ae...@op...>]

Markus Hoenicka wrote:
> Hi,
> 

Hi. Thanks for the quick reply :)

> Quoting Andreas Ericsson <ae...@op...>:
> 
>> My dev-box uses libdbi 0.8.3, but the build-box uses 0.8.1. Some
>> functions I'd like to use (dbi_conn_escape_string_copy() among
>> others) are in 0.8.3, but not in 0.8.2. I suppose I could convert
>> all the queries to use dbi_conn_quote_string_copy() instead, but
>> since it's not performance critical I've decided to write a small
>> wrapper and remove the quotation marks instead (there are rather
>> a lot of queries).
>>
>> This shouldn't be much of a problem, but I can't seem to find
>> any versioning macro telling me what version of the library I'm
>> currently building against. The LIBDBI_LIB_{CURRENT,REVISION,AGE}
>> macros are useless for this, since the ABI hasn't changed, and
>> thus the .so-version remains the same, and new functionality
>> added in a backwards compatible way (the preferred way, one would
>> think) won't bump it either, which means that new functionality
>> really can't be used portably until the ABI breaks, which sucks
>> quite tremenduously.
>>
> 
> This is one of the dusty corners in libdbi (and I know it sucks). No 
> one, myself included, proved wise enough to update the 
> LIB_{CURRENT,REVISION,AGE} for quite a while.

But aren't those determining the .so-version as well? If so, it wouldn't
be correct to update them with micro-releases, since the linker would
believe a later version is incompatible with an earlier one.

The best trick is probably to utilize the vcs versioning numbers and
use a script to cut releases. Sadly, I have no idea how to make that
work in cvs, although I could do it blindfolded in git, hint hint ;-)

> This problem was noticed a 
> year ago, and release 1.0 will be the first one which has this 
> information correct again. From that release on you'll be able to use 
> these constants with all their benefits.
> 

Sounds awesome, but I'd still invite you to give some serious thought
to having it be updated automagically when you cut a release. Any manual
labour is bound to go stale sooner or later.

> For the time being you'd have to write configure tests which look for 
> the functions that you want to call. For libdbi releases up to 0.8.3 
> this is the only reliable way to test for the presence of these 
> functions. Let me know if you need further assistance.
> 

Ugh. That's more complexity than it's worth. I've just hacked around it
using a wrapper for dbi_conn_quote_string_copy() atm. It suffices for
my needs. Thanks for the tip though. I'll look into it if I run into
anything I can't work around in some other way.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [libdbi-devel] Library version macro

[Markus H. <mar...@mh...>]

Hi,

Quoting Andreas Ericsson <ae...@op...>:

> My dev-box uses libdbi 0.8.3, but the build-box uses 0.8.1. Some
> functions I'd like to use (dbi_conn_escape_string_copy() among
> others) are in 0.8.3, but not in 0.8.2. I suppose I could convert
> all the queries to use dbi_conn_quote_string_copy() instead, but
> since it's not performance critical I've decided to write a small
> wrapper and remove the quotation marks instead (there are rather
> a lot of queries).
>
> This shouldn't be much of a problem, but I can't seem to find
> any versioning macro telling me what version of the library I'm
> currently building against. The LIBDBI_LIB_{CURRENT,REVISION,AGE}
> macros are useless for this, since the ABI hasn't changed, and
> thus the .so-version remains the same, and new functionality
> added in a backwards compatible way (the preferred way, one would
> think) won't bump it either, which means that new functionality
> really can't be used portably until the ABI breaks, which sucks
> quite tremenduously.
>

This is one of the dusty corners in libdbi (and I know it sucks). No  
one, myself included, proved wise enough to update the  
LIB_{CURRENT,REVISION,AGE} for quite a while. This problem was noticed  
a year ago, and release 1.0 will be the first one which has this  
information correct again. From that release on you'll be able to use  
these constants with all their benefits.

For the time being you'd have to write configure tests which look for  
the functions that you want to call. For libdbi releases up to 0.8.3  
this is the only reliable way to test for the presence of these  
functions. Let me know if you need further assistance.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] Library version macro

[Andreas E. <ae...@op...>]

Hi there libdbi developers.

I'm currently converting an application from mysql-only to libdbi,
but I've run across a rather irritating problem.

My dev-box uses libdbi 0.8.3, but the build-box uses 0.8.1. Some
functions I'd like to use (dbi_conn_escape_string_copy() among
others) are in 0.8.3, but not in 0.8.2. I suppose I could convert
all the queries to use dbi_conn_quote_string_copy() instead, but
since it's not performance critical I've decided to write a small
wrapper and remove the quotation marks instead (there are rather
a lot of queries).

This shouldn't be much of a problem, but I can't seem to find
any versioning macro telling me what version of the library I'm
currently building against. The LIBDBI_LIB_{CURRENT,REVISION,AGE}
macros are useless for this, since the ABI hasn't changed, and
thus the .so-version remains the same, and new functionality
added in a backwards compatible way (the preferred way, one would
think) won't bump it either, which means that new functionality
really can't be used portably until the ABI breaks, which sucks
quite tremenduously.

Note that the dbi_version() function can't be used for this, as
any conditional based on its return value has to be done at run-
time.

I tried poking around in the build-system, but I can't seem to
find where the current version is set, so I can't submit a patch
to add such a macro. Any pointers?

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [libdbi-devel] [patch] Fixed bug in mysql driver when using multiple statement queries

[Nicolas Morey-C. <de...@mo...>]

Markus Hoenicka a écrit :
> Hi,
>
> thanks for bringing this to our attention. While your patch may cure
> the symptoms, I don't think it's the proper way to handle this
> problem. After all, your approach simply tosses all results of
> multiple statement queries except the first one. 

The thing is for INSERT or UPDATE queries, there is actually no results
returned. It just a bunch of NULL pointers, so my workaround doesn't
lose any data.
The only problem is, I agree, with multiple SELECT.
With Postgres, i'm running multiple INSERT/UPDATE without any problem. I
haven't tried to run multiple SELECT but i guess there are some prioblem
too as the libdbi API seems not to be fitted for multiple SELECT.

In my opinion, handling multiple query for query without any result send
back is acceptable as long as it is well documented.
> Writing your app in a
> way that prevents multiple statement queries will provide the same
> results without unwanted side effects. 
The problem is my app is a performance plugin and gets about 10000
updates to do in the database, and on Postgres it's much faster when
using multiple queries.

> I think it is more honest to
> admit that libdbi does not yet support multiple statement queries at
> this time and add this to the documentation.
>
>   
I agree, but as I said supporting only multiple queries without "real"
result (only NULL pointers) seems to me like an acceptable behaviour.
> Thanks anyway for looking into this and for suggesting a patch.
>
> regards,
> Markus
>
> Nicolas Morey-Chaisemartin writes:
>  > (sent to the libdbi-dev mailing list but forgot to put you in copy)
>  > 
>  > Hello everyone,
>  > 
>  > I am using libdbi for one of my application. It was working perfectly
>  > fine with Postgre but I had some troubles with MySQL.
>  > After looking a bit around, i found out I had to install the last libdbi
>  > drivers to be able to use multiple statements with MySQL.
>  > I checked the sources and libdbi-drivers-0.8.3-1 takes the mysql multi
>  > statement option and pass it to MySQL when connecting.
>  > 
>  > The problem is when you are doing a multi statement query, mysql is
>  > generating multiple results. Even if you do a couple of INSERT.
>  > As long as all these results have not been read, MySQL will return a
>  > 2014 (out of sync) error to any query.
>  > 
>  > I've quickly patch the driver so it'll eat all the results and return
>  > the first one.
>  > It will manage the case where statements are INSERT or UPDATES but some
>  > data will be lost when several SELECT are done in a single query.
>  > 
>  > I've tested it and it solves my problem.
>  > I guess a more generic solution should be developped but I really don't
>  > have time for this right now.
>  > 
>  > Regards
>  > 
>  > Nicolas Morey-Chaisemartin
>  > 
>  > 
>  > *** drivers/mysql/dbd_mysql.c.orig	2008-01-15 01:27:29.000000000 +0100
>  > --- drivers/mysql/dbd_mysql.c	2008-12-29 18:04:26.000000000 +0100
>  > ***************
>  > *** 506,511 ****
>  > --- 506,513 ----
>  >   	
>  >   	res = mysql_store_result((MYSQL *)conn->connection);
>  >   	
>  > + 	while(mysql_next_result((MYSQL *)conn->connection) == 0)
>  > + 		mysql_free_result(mysql_store_result((MYSQL *)conn->connection));
>  >   	/* if res is null, the query was something that doesn't return rows (like an INSERT) */
>  >   	result = _dbd_result_create(conn, (void *)res, (res ? mysql_num_rows(res) : 0), 
>  >   								mysql_affected_rows((MYSQL *)conn->connection));
>  > ***************
>  > *** 528,533 ****
>  > --- 530,537 ----
>  >   	
>  >   	res = mysql_store_result((MYSQL *)conn->connection);
>  >   	
>  > + 	while(mysql_next_result((MYSQL *)conn->connection) == 0)
>  > + 		mysql_free_result(mysql_store_result((MYSQL *)conn->connection));
>  >   	/* if res is null, the query was something that doesn't return rows (like an INSERT) */
>  >   	result = _dbd_result_create(conn, (void *)res, (res ? mysql_num_rows(res) : 0), 
>  >   								mysql_affected_rows((MYSQL *)conn->connection));
>  > 
>  > 
>
>   

[libdbi-devel] [patch] Fixed bug in mysql driver when using multiple statement queries

[Markus H. <mar...@mh...>]

Hi,

thanks for bringing this to our attention. While your patch may cure
the symptoms, I don't think it's the proper way to handle this
problem. After all, your approach simply tosses all results of
multiple statement queries except the first one. Writing your app in a
way that prevents multiple statement queries will provide the same
results without unwanted side effects. I think it is more honest to
admit that libdbi does not yet support multiple statement queries at
this time and add this to the documentation.

Thanks anyway for looking into this and for suggesting a patch.

regards,
Markus

Nicolas Morey-Chaisemartin writes:
 > (sent to the libdbi-dev mailing list but forgot to put you in copy)
 > 
 > Hello everyone,
 > 
 > I am using libdbi for one of my application. It was working perfectly
 > fine with Postgre but I had some troubles with MySQL.
 > After looking a bit around, i found out I had to install the last libdbi
 > drivers to be able to use multiple statements with MySQL.
 > I checked the sources and libdbi-drivers-0.8.3-1 takes the mysql multi
 > statement option and pass it to MySQL when connecting.
 > 
 > The problem is when you are doing a multi statement query, mysql is
 > generating multiple results. Even if you do a couple of INSERT.
 > As long as all these results have not been read, MySQL will return a
 > 2014 (out of sync) error to any query.
 > 
 > I've quickly patch the driver so it'll eat all the results and return
 > the first one.
 > It will manage the case where statements are INSERT or UPDATES but some
 > data will be lost when several SELECT are done in a single query.
 > 
 > I've tested it and it solves my problem.
 > I guess a more generic solution should be developped but I really don't
 > have time for this right now.
 > 
 > Regards
 > 
 > Nicolas Morey-Chaisemartin
 > 
 > 
 > *** drivers/mysql/dbd_mysql.c.orig	2008-01-15 01:27:29.000000000 +0100
 > --- drivers/mysql/dbd_mysql.c	2008-12-29 18:04:26.000000000 +0100
 > ***************
 > *** 506,511 ****
 > --- 506,513 ----
 >   	
 >   	res = mysql_store_result((MYSQL *)conn->connection);
 >   	
 > + 	while(mysql_next_result((MYSQL *)conn->connection) == 0)
 > + 		mysql_free_result(mysql_store_result((MYSQL *)conn->connection));
 >   	/* if res is null, the query was something that doesn't return rows (like an INSERT) */
 >   	result = _dbd_result_create(conn, (void *)res, (res ? mysql_num_rows(res) : 0), 
 >   								mysql_affected_rows((MYSQL *)conn->connection));
 > ***************
 > *** 528,533 ****
 > --- 530,537 ----
 >   	
 >   	res = mysql_store_result((MYSQL *)conn->connection);
 >   	
 > + 	while(mysql_next_result((MYSQL *)conn->connection) == 0)
 > + 		mysql_free_result(mysql_store_result((MYSQL *)conn->connection));
 >   	/* if res is null, the query was something that doesn't return rows (like an INSERT) */
 >   	result = _dbd_result_create(conn, (void *)res, (res ? mysql_num_rows(res) : 0), 
 >   								mysql_affected_rows((MYSQL *)conn->connection));
 > 
 > 

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] [patch] Fixed bug in mysql driver when using multiple statement queries

[Nicolas Morey-C. <de...@mo...>]

Hello everyone,

I am using libdbi for one of my application. It was working perfectly
fine with Postgre but I had some troubles with MySQL.
After looking a bit around, i found out I had to install the last libdbi
drivers to be able to use multiple statements with MySQL.
I checked the sources and libdbi-drivers-0.8.3-1 takes the mysql multi
statement option and pass it to MySQL when connecting.

The problem is when you are doing a multi statement query, mysql is
generating multiple results. Even if you do a couple of INSERT.
As long as all these results have not been read, MySQL will return a
2014 (out of sync) error to any query.

I've quickly patch the driver so it'll eat all the results and return
the first one.
It will manage the case where statements are INSERT or UPDATES but some
data will be lost when several SELECT are done in a single query.

I've tested it and it solves my problem.
I guess a more generic solution should be developped but I really don't
have time for this right now.

Regards

Nicolas Morey-Chaisemartin

[libdbi-devel] [PATCH] src/dbi_main.c: Remove two unused variables.

[Markus H. <mar...@mh...>]

Florian Forster writes:
 > From: Florian Forster <oc...@ve...>

I've applied the patches you sent and checked in the patched
files. Thanks again for contributing.

Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] [PATCH] src/dbi_main.c: Remove two unused variables.

[Markus H. <mar...@mh...>]

Thanks for the impressive patchkit. I've already taken care of the  
first one yesterday, but the other 97 :-) are more than welcome. I'll  
apply and test those tonight.

regards,
Markus

Quoting Florian Forster <sou...@no...>:

> From: Florian Forster <oc...@ve...>
>
> ---
>  src/dbi_main.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/src/dbi_main.c b/src/dbi_main.c
> index c80adff..e3b7e90 100644
> --- a/src/dbi_main.c
> +++ b/src/dbi_main.c
> @@ -780,7 +780,6 @@ size_t dbi_conn_quote_binary_copy(dbi_conn Conn,  
>  const unsigned char *orig, size
>     do */
>
>  size_t dbi_conn_escape_string_copy(dbi_conn Conn, const char *orig,  
>  char **newquoted) {
> -	char *newstr;
>  	size_t newlen;
>
>  	if (!Conn) {
> @@ -1247,7 +1246,6 @@ static dbi_driver_t *_get_driver(const char   
> *filename, dbi_inst_t *inst) {
>  	unsigned int idx = 0;
>  	dbi_custom_function_t *prevcustom = NULL;
>  	dbi_custom_function_t *custom = NULL;
> -	char function_name[256];
>  	const char* error;
>
>  	dlhandle = my_dlopen(filename, DLOPEN_FLAG); /* DLOPEN_FLAG   
> defined by autoconf */
> --
> 1.5.6.5
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> libdbi-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-devel
>



-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] [PATCH] src/dbi_main.c: Make sure all functions return what they should.

[Florian F. <sou...@no...>]

From: Florian Forster <oc...@ve...>

`dbi_initialize' and `dbi_conn_new' did not return anything although they
are non-void.
---
 src/dbi_main.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/dbi_main.c b/src/dbi_main.c
index 1afbccb..c80adff 100644
--- a/src/dbi_main.c
+++ b/src/dbi_main.c
@@ -234,7 +234,7 @@ int dbi_initialize_r(const char *driverdir, dbi_inst *pInst) {
 }
 
 int dbi_initialize(const char *driverdir) {
-	dbi_initialize_r(driverdir, &dbi_inst_legacy);
+	return (dbi_initialize_r(driverdir, &dbi_inst_legacy));
 }
 
 void dbi_shutdown_r(dbi_inst Inst) {
@@ -529,7 +529,7 @@ dbi_conn dbi_conn_new_r(const char *name, dbi_inst Inst) {
 	return conn;
 }
 dbi_conn dbi_conn_new(const char *name) {
-	dbi_conn_new_r(name, dbi_inst_legacy);
+	return dbi_conn_new_r(name, dbi_inst_legacy);
 }
 
 dbi_conn dbi_conn_open(dbi_driver Driver) {
-- 
1.5.6.5

[libdbi-devel] [PATCH] configure.in: Check if (v)asprintf is declared.

[Florian F. <sou...@no...>]

From: Florian Forster <oc...@ve...>

Checking if the library has the required symbol is not enough. If we
specify standard-compliance headers those functions may not be declared.
---
 configure.in   |    8 +++-----
 src/dbi_main.c |    4 ++--
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/configure.in b/configure.in
index d31dd73..f434239 100644
--- a/configure.in
+++ b/configure.in
@@ -150,11 +150,9 @@ AC_ARG_WITH(dlsym-prefix,
 AC_DEFINE_UNQUOTED(DRIVER_EXT, "$shlib_ext", [ Specifies the filename extension of loadable modules ])
 AC_DEFINE_UNQUOTED(DLSYM_PREFIX, "$dlsym_prefix", [ Specifies a required prefix for symbol names of dynamically loaded modules ])
 
-
-AC_CHECK_FUNCS(strtoll readdir_r gmtime_r fpathconf dirfd)
-AC_REPLACE_FUNCS(atoll timegm)
-AC_CHECK_FUNCS(vasprintf)
-AC_REPLACE_FUNCS(asprintf)
+AC_CHECK_DECLS([readdir_r, gmtime_r, vasprintf, asprintf])
+AC_CHECK_FUNCS(strtoll readdir_r gmtime_r fpathconf dirfd vasprintf)
+AC_REPLACE_FUNCS(atoll timegm asprintf)
 
 dnl ==============================
 dnl Checks for header files
diff --git a/src/dbi_main.c b/src/dbi_main.c
index 3902267..43fc08d 100644
--- a/src/dbi_main.c
+++ b/src/dbi_main.c
@@ -110,10 +110,10 @@ char *win_dlerror();
 #endif
 
 /* declarations of optional external functions */
-#ifndef HAVE_VASPRINTF
+#if !HAVE_DECL_VASPRINTF
 int vasprintf(char **result, const char *format, va_list args);
 #endif
-#ifndef HAVE_ASPRINTF
+#if !HAVE_DECL_ASPRINTF
 int asprintf(char **result, const char *format, ...);
 #endif
 
-- 
1.5.6.5

[libdbi-devel] [PATCH] include/dbi/dbi.h.in: Put an `#ifndef' around the LIBDBI_API_DEPRECATED definition.

[Florian F. <sou...@no...>]

From: Florian Forster <oc...@ve...>

This way src/dbi_main.c can deactivate those attributes when implementing
the functions. For example, `dbi_driver_quote_string' uses
`dbi_driver_quote_string_copy', which is perfectly reasonable although
both functions are deprecated.
---
 include/dbi/dbi.h.in |   14 ++++++++------
 src/dbi_main.c       |    2 ++
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/include/dbi/dbi.h.in b/include/dbi/dbi.h.in
index 3b26da5..b049844 100644
--- a/include/dbi/dbi.h.in
+++ b/include/dbi/dbi.h.in
@@ -32,12 +32,14 @@ extern "C" {
 #include <time.h>
 #include <limits.h> /* for the *_MAX definitions */
 
-#if defined _MSC_VER && _MSC_VER >= 1300
-#define LIBDBI_API_DEPRECATED __declspec(deprecated)
-#elif defined __GNUC__ && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 2))
-#define LIBDBI_API_DEPRECATED __attribute__((__deprecated__))
-#else
-#define LIBDBI_API_DEPRECATED
+#ifndef LIBDBI_API_DEPRECATED
+# if defined _MSC_VER && _MSC_VER >= 1300
+#  define LIBDBI_API_DEPRECATED __declspec(deprecated)
+# elif defined __GNUC__ && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 2))
+#  define LIBDBI_API_DEPRECATED __attribute__((__deprecated__))
+# else
+#  define LIBDBI_API_DEPRECATED /**/
+# endif
 #endif
 
 /* opaque type definitions */
diff --git a/src/dbi_main.c b/src/dbi_main.c
index 43fc08d..1eb6819 100644
--- a/src/dbi_main.c
+++ b/src/dbi_main.c
@@ -20,6 +20,8 @@
  * $Id: dbi_main.c,v 1.89 2008/11/27 21:55:57 mhoenicka Exp $
  */
 
+#define LIBDBI_API_DEPRECATED /**/
+
 #ifdef HAVE_CONFIG_H
 #include <config.h>
 #endif
-- 
1.5.6.5

[libdbi-devel] [PATCH] src/dbi_main.c: Remove two unused variables.

[Florian F. <sou...@no...>]

From: Florian Forster <oc...@ve...>

---
 src/dbi_main.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/src/dbi_main.c b/src/dbi_main.c
index c80adff..e3b7e90 100644
--- a/src/dbi_main.c
+++ b/src/dbi_main.c
@@ -780,7 +780,6 @@ size_t dbi_conn_quote_binary_copy(dbi_conn Conn, const unsigned char *orig, size
    do */
 
 size_t dbi_conn_escape_string_copy(dbi_conn Conn, const char *orig, char **newquoted) {
-	char *newstr;
 	size_t newlen;
 	
 	if (!Conn) {
@@ -1247,7 +1246,6 @@ static dbi_driver_t *_get_driver(const char *filename, dbi_inst_t *inst) {
 	unsigned int idx = 0;
 	dbi_custom_function_t *prevcustom = NULL;
 	dbi_custom_function_t *custom = NULL;
-	char function_name[256];
 	const char* error;
 
 	dlhandle = my_dlopen(filename, DLOPEN_FLAG); /* DLOPEN_FLAG defined by autoconf */
-- 
1.5.6.5

[libdbi-devel] [PATCH] src/dbi_result.c: Make sure all `errflag's are defined before being used.

[Florian F. <sou...@no...>]

From: Florian Forster <oc...@ve...>

---
 src/dbi_result.c |   38 +++++++++++++++++++-------------------
 1 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/src/dbi_result.c b/src/dbi_result.c
index 249a7bf..88018aa 100644
--- a/src/dbi_result.c
+++ b/src/dbi_result.c
@@ -214,7 +214,7 @@ unsigned long long dbi_result_get_numrows_affected(dbi_result Result) {
 /* returns the length of the string or binary, excluding a trailing \0 */
 size_t dbi_result_get_field_length(dbi_result Result, const char *fieldname) {
   unsigned int fieldidx = 0;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   if (!RESULT) {
     _error_handler(/*RESULT->conn*/ NULL, DBI_ERROR_BADPTR);
@@ -273,7 +273,7 @@ size_t dbi_result_get_field_size_idx(dbi_result Result, unsigned int fieldidx) {
 
 unsigned int dbi_result_get_field_idx(dbi_result Result, const char *fieldname) {
   unsigned int fieldidx = 0;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   if (!RESULT) {
     _error_handler(/*RESULT->conn*/ NULL, DBI_ERROR_BADPTR);
@@ -323,7 +323,7 @@ unsigned int dbi_result_get_numfields(dbi_result Result) {
 
 unsigned short dbi_result_get_field_type(dbi_result Result, const char *fieldname) {
   unsigned int fieldidx = 0;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 	
   if (!RESULT) {
     _error_handler(/*RESULT->conn*/ NULL, DBI_ERROR_BADPTR);
@@ -365,7 +365,7 @@ unsigned short dbi_result_get_field_type_idx(dbi_result Result, unsigned int fie
 
 unsigned int dbi_result_get_field_attrib(dbi_result Result, const char *fieldname, unsigned int attribmin, unsigned int attribmax) {
   unsigned int fieldidx = 0;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 	
   if (!RESULT) {
     _error_handler(/*RESULT->conn*/ NULL, DBI_ERROR_BADPTR);
@@ -408,7 +408,7 @@ unsigned int dbi_result_get_field_attrib_idx(dbi_result Result,
 
 unsigned int dbi_result_get_field_attribs(dbi_result Result, const char *fieldname) {
   unsigned int fieldidx = 0;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 	
   if (!RESULT) {
     _error_handler(/*RESULT->conn*/ NULL, DBI_ERROR_BADPTR);
@@ -462,7 +462,7 @@ int _get_field_flag(dbi_row_t *row, unsigned int fieldidx, unsigned char flag) {
 
 int dbi_result_field_is_null(dbi_result Result, const char *fieldname) {
   unsigned int fieldidx = 0;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   if (!RESULT) {
     _error_handler(/*RESULT->conn*/ NULL, DBI_ERROR_BADPTR);
@@ -812,7 +812,7 @@ unsigned int dbi_result_bind_fields(dbi_result Result, const char *format, ...)
 signed char dbi_result_get_char(dbi_result Result, const char *fieldname) {
   signed char ERROR = 0;
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   _reset_conn_error(RESULT->conn);
 
@@ -861,7 +861,7 @@ signed char dbi_result_get_char_idx(dbi_result Result, unsigned int fieldidx) {
 short dbi_result_get_short(dbi_result Result, const char *fieldname) {
   short ERROR = 0;
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   _reset_conn_error(RESULT->conn);
 
@@ -913,7 +913,7 @@ int dbi_result_get_long(dbi_result Result, const char *fieldname) {
 int dbi_result_get_int(dbi_result Result, const char *fieldname) {
   long ERROR = 0;
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   _reset_conn_error(RESULT->conn);
 
@@ -965,7 +965,7 @@ int dbi_result_get_int_idx(dbi_result Result, unsigned int fieldidx) {
 long long dbi_result_get_longlong(dbi_result Result, const char *fieldname) {
   long long ERROR = 0;
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
     
   _reset_conn_error(RESULT->conn);
 
@@ -1050,7 +1050,7 @@ unsigned long long dbi_result_get_ulonglong_idx(dbi_result Result, unsigned int
 
 float dbi_result_get_float(dbi_result Result, const char *fieldname) {
   float ERROR = 0.0;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
   unsigned int fieldidx;
 
   _reset_conn_error(RESULT->conn);
@@ -1097,7 +1097,7 @@ float dbi_result_get_float_idx(dbi_result Result, unsigned int fieldidx) {
 double dbi_result_get_double(dbi_result Result, const char *fieldname) {
   double ERROR = 0.0;
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   _reset_conn_error(RESULT->conn);
 
@@ -1140,7 +1140,7 @@ double dbi_result_get_double_idx(dbi_result Result, unsigned int fieldidx) {
 const char *dbi_result_get_string(dbi_result Result, const char *fieldname) {
   const char *ERROR = "ERROR";
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   _reset_conn_error(RESULT->conn);
 
@@ -1185,7 +1185,7 @@ const char *dbi_result_get_string_idx(dbi_result Result, unsigned int fieldidx)
 const unsigned char *dbi_result_get_binary(dbi_result Result, const char *fieldname) {
   const char *ERROR = "ERROR";
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   _reset_conn_error(RESULT->conn);
 
@@ -1223,7 +1223,7 @@ const unsigned char *dbi_result_get_binary_idx(dbi_result Result, unsigned int f
 char *dbi_result_get_string_copy(dbi_result Result, const char *fieldname) {
   char *ERROR = "ERROR";
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   _reset_conn_error(RESULT->conn);
 
@@ -1275,7 +1275,7 @@ char *dbi_result_get_string_copy_idx(dbi_result Result, unsigned int fieldidx) {
 unsigned char *dbi_result_get_binary_copy(dbi_result Result, const char *fieldname) {
   char *ERROR = "ERROR";
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   _reset_conn_error(RESULT->conn);
 
@@ -1323,7 +1323,7 @@ unsigned char *dbi_result_get_binary_copy_idx(dbi_result Result, unsigned int fi
 time_t dbi_result_get_datetime(dbi_result Result, const char *fieldname) {
   time_t ERROR = 0;
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   _reset_conn_error(RESULT->conn);
 
@@ -1361,7 +1361,7 @@ time_t dbi_result_get_datetime_idx(dbi_result Result, unsigned int fieldidx) {
 long long dbi_result_get_as_longlong(dbi_result Result, const char *fieldname) {
   long long ERROR = 0;
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
     
   _reset_conn_error(RESULT->conn);
 
@@ -1426,7 +1426,7 @@ long long dbi_result_get_as_longlong_idx(dbi_result Result, unsigned int fieldid
 char *dbi_result_get_as_string_copy(dbi_result Result, const char *fieldname) {
   char *ERROR = "ERROR";
   unsigned int fieldidx;
-  dbi_error_flag errflag;
+  dbi_error_flag errflag = DBI_ERROR_NONE;
 
   _reset_conn_error(RESULT->conn);
 
-- 
1.5.6.5

[libdbi-devel] [PATCH] src/dbi_main.c: Cast an `const unsigned char *' to a `const char *'.

[Florian F. <sou...@no...>]

From: Florian Forster <oc...@ve...>

---
 src/dbi_main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/dbi_main.c b/src/dbi_main.c
index e3b7e90..e103dfc 100644
--- a/src/dbi_main.c
+++ b/src/dbi_main.c
@@ -1162,7 +1162,7 @@ dbi_result dbi_conn_query_null(dbi_conn Conn, const unsigned char *statement, si
 
 	_reset_conn_error(conn);
 
-	_logquery_null(conn, statement, st_length);
+	_logquery_null(conn, (const char *) statement, st_length);
 	result = conn->driver->functions->query_null(conn, statement, st_length);
 
 	if (result == NULL) {
-- 
1.5.6.5