Re: [libdbi-users] dbi_result_get_ulonglong overflow
Devin Reade writes: > I'm going to have to take a step back for a moment: Currently the only > thing that I have that is using libdbi is one legacy application. I'm > not saying that I won't use it in future projects, just that I have no > active projects at the moment depending on it. Therefore other users > may have more of an opinion. (I originally stepped into this conversation > to answer the "what's wrong with ato*?" question on a more theoretical > basis.) > I'm sorry about that, I've left you in the To: field unintentionally - I wanted to solicit some opinions from the list instead. But thanks anyway for providing your thoughts on this matter. regards, Markus > Also, your userbase may be wary of anything that results > in an API change, at least between minor versions. Even if you can't > propagate an error, you should be able to log the problem, though. > > That being said, I do not think that it is unreasonable for dbd_fetch_row > to error out if there is a problem parsing any of the result columns. > One should be able to determine (from log files, if not programatically) > the set of all problems in that case, though. > > Devin > -- > I'm not a complete idiot, some parts are missing. > > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > libdbi-users mailing list > libdbi-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libdbi-users -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Markus Hoenicka wrote: > I've had a look at libdbi-driver's current ato*() usage. As far as I > can see it is used only to turn raw row data into integers by > functions which do not return values, i.e. without an easy way to > indicate conversion errors. I haven't checked all drivers yet, but I > see two options: [snip] I'm going to have to take a step back for a moment: Currently the only thing that I have that is using libdbi is one legacy application. I'm not saying that I won't use it in future projects, just that I have no active projects at the moment depending on it. Therefore other users may have more of an opinion. (I originally stepped into this conversation to answer the "what's wrong with ato*?" question on a more theoretical basis.) Also, your userbase may be wary of anything that results in an API change, at least between minor versions. Even if you can't propagate an error, you should be able to log the problem, though. That being said, I do not think that it is unreasonable for dbd_fetch_row to error out if there is a problem parsing any of the result columns. One should be able to determine (from log files, if not programatically) the set of all problems in that case, though. Devin -- I'm not a complete idiot, some parts are missing. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Devin Reade writes: > In the particular case of this use in libdbi, I've not looked at the > code to see to what extent it is an *actual* problem; however as a > generalization, I would advise against using ato*() functions and instead > use strto*() functions because the latter provides input error checks > that the former does not. I've had a look at libdbi-driver's current ato*() usage. As far as I can see it is used only to turn raw row data into integers by functions which do not return values, i.e. without an easy way to indicate conversion errors. I haven't checked all drivers yet, but I see two options: 1) make the functions in question return error codes. This would allow dbd_fetch_row() to return an error code as well. However, an error in a single field would make the operation fail. 2) use a field flag to tag the affected field only. This would require users to check integer fields manually, in a similar fashion as you have to check for NULL values if this is relevant. What do you think? regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Devin Reade writes: > They should at least be as portable as the ato* functions, unless > perhaps someone is still using a K&R C compiler somewhere, which > I doubt. If there's any portability issue, I would expect it to > rear its head more for the 'long long' versions of both rather than > ato* vs strto*. > I've checked the repository. Obviously atoll() was missing from MinGW (for the more or less native Windows port of libdbi). Does anyone happen to know if MinGW still lacks atoll()/strtoll() support these days? In any case, we stole an atoll() implementation from MySQL back then, which upon close inspection also turns out to be implemented via its own strtoll(). Therefore switching from ato*() to strto*() should not hurt. > That being said, the only real test is empirical. > True indeed. I'll look into this. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Markus Hoenicka wrote: > What about the portability of the strto* functions? They should at least be as portable as the ato* functions, unless perhaps someone is still using a K&R C compiler somewhere, which I doubt. If there's any portability issue, I would expect it to rear its head more for the 'long long' versions of both rather than ato* vs strto*. That being said, the only real test is empirical. Devin -- You can't be truly paranoid unless you're sure they have already got you.- Pavel Kankovsky -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Devin Reade writes: > The ato* are indeed often implemented in terms of strto*. The problem > is that the ato* signature just doesn't lend itself to error > checks, so even if they wrap strto*, error information gets lost in > the wrapper layer. What about the portability of the strto* functions? I recall we had to add an implementation of atoll() to the libdbi sources to compile it on at least one platform (I can't quite recall which one). Can we expect that all platforms which are currently supported provide all required strto*() functions? regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Markus Hoenicka wrote: > I guess I have incorrectly generalized > from FreeBSD that ato*() are wrappers around the corresponding > strto*() functions. If they are indeed separately implemented in other > OSes, [snip] The ato* are indeed often implemented in terms of strto*. The problem is that the ato* signature just doesn't lend itself to error checks, so even if they wrap strto*, error information gets lost in the wrapper layer. Devin -- Money is a powerful aphrodisiac. But flowers work almost as well. - Robert Heinlein -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Devin Reade was heard to say: > Markus Hoenicka wrote: > >> To better deal with your shock: Could you please elaborate what's >> wrong with atoll()? > > In the particular case of this use in libdbi, I've not looked at the > code to see to what extent it is an *actual* problem; however as a > generalization, I would advise against using ato*() functions and instead > use strto*() functions because the latter provides input error checks > that the former does not. For example, if someone provides "073Ah" as > input (thinking of the old DOS style hex stuff), what do they get? > > atol: 0x49 with no indication that the whole string wasn't parsed > strtol: 0x3B, with an indication that the "Ah" wasn't parsed (assuming > a zero base) or 0x73a with an indication that 'h' wasn't parsed > (assuming a base of 16). > > In code inspections, ato*() is something my eye is drawn to as a > potential source of problems, just as gotos are. I don't remember if > ato*() were mentioned in the classic paper > "Can't Happen or /*NOT REACHED*/ or Real Programs Drop Core" > but if not they should have been. > Thanks for elaborating on this. I guess I have incorrectly generalized from FreeBSD that ato*() are wrappers around the corresponding strto*() functions. If they are indeed separately implemented in other OSes, you have a good point in avoiding ato*() functions in libdbi. A quick look at the code suggests indeed that there is insufficient error checking on the return of the string to number conversions. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Markus Hoenicka wrote: > To better deal with your shock: Could you please elaborate what's > wrong with atoll()? In the particular case of this use in libdbi, I've not looked at the code to see to what extent it is an *actual* problem; however as a generalization, I would advise against using ato*() functions and instead use strto*() functions because the latter provides input error checks that the former does not. For example, if someone provides "073Ah" as input (thinking of the old DOS style hex stuff), what do they get? atol: 0x49 with no indication that the whole string wasn't parsed strtol: 0x3B, with an indication that the "Ah" wasn't parsed (assuming a zero base) or 0x73a with an indication that 'h' wasn't parsed (assuming a base of 16). In code inspections, ato*() is something my eye is drawn to as a potential source of problems, just as gotos are. I don't remember if ato*() were mentioned in the classic paper "Can't Happen or /*NOT REACHED*/ or Real Programs Drop Core" but if not they should have been. My $0.02 Devin -- Money is a powerful aphrodisiac. But flowers work almost as well. - Robert Heinlein -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Quoting Vikram Noel Ambrose : > I was pretty shocked to see an atoll call in libdbi. But there is no > point on going on about that. > To better deal with your shock: Could you please elaborate what's wrong with atoll()? I recall from my home platform (FreeBSD) that atoll() is merely a wrapper around strtoll() anyways. So do you mind the use of atoll() per se or the lack of a potentially necessary discrimination between strtoll() and strtoull()? regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Vikram Noel Ambrose wrote: > I can't seem to read back BIGINT UNSIGNED (8bytes) from a mysql database. > > For example: > A value of "10988581603938712255" = 0x987F48BFB028BABF > is returned as "9223372036854775807" = 0x7FFF > > Something somewhere is capping off my BIGINT UNSIGNED to the maximum > of a signed 8byte number. > > I'm using libdbi-0.8.3 on Ubuntu-9.10 X86_64. > > > Vikram. > > > I think I may have found the cause of the problem: Line:726 in dbd_mysql.c data->d_longlong = (long long) atoll(raw); break; I was pretty shocked to see an atoll call in libdbi. But there is no point on going on about that. Just as a hack, I replaced it with, strtoull(raw,NULL,10); and it seems to be working. Obviously this is not going to work with actual signed and negative numbers. How do we fix this? Vikram. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
[libdbi-users] dbi_result_get_ulonglong overflow
I can't seem to read back BIGINT UNSIGNED (8bytes) from a mysql database. For example: A value of "10988581603938712255" = 0x987F48BFB028BABF is returned as "9223372036854775807" = 0x7FFF Something somewhere is capping off my BIGINT UNSIGNED to the maximum of a signed 8byte number. I'm using libdbi-0.8.3 on Ubuntu-9.10 X86_64. Vikram. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users
