Re: [libdbi-users] dbi_result_get_ulonglong overflow
Markus Hoenicka markus.hoeni...@mhoenicka.de 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: 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
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
Re: [libdbi-users] dbi_result_get_ulonglong overflow
Markus Hoenicka markus.hoeni...@mhoenicka.de 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