Thread: [Mysql-cocoa-users] Bug with BigInt data types
Brought to you by:
sergecohen
Menu
▾
▴
mysql-cocoa-users
|
From: Lorenz T. <lo...@te...> - 2003-08-19 09:45:16
|
Hi everybody, It seems that in the SMySQL framework BigInt data types are limited to a max value of 2147483647, while MySQL allows 64 (63) bit integer values. Does anybody know how to fix that? I think that the [NSNumber numberWithLong:atol(theData)]; isn't appropriate for BigInt values, but I'm not sure what would be right here... Thanks for your help Lorenz |
|
From: Serge C. <ser...@us...> - 2003-08-19 11:26:55
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi=0D =0D If I understand properly the MySQL documentation, we have the following =0D= sizes for integer storage:=0D =0D - - SMALLINT : 16 bits (short int in C).=0D - - MEDIUMINT : 24 bits (inexistent in C).=0D - - INT or INTEGER : 32 bits (int in C).=0D - - BIGINT : 64 bits (long int in C).=0D =0D So I don't see why the atol function should not work properly for =0D integers in the range -9223372036854775808 to 9223372036854775807 =0D (though I guess it will not be happy if you use UNSIGNED BIGINT, which =0D= are corresponding to unsigned long int... which atol can not produce, =0D= you will get unexepected result with UNSIGNED BIGINT > =0D 9223372036854775807)...=0D =0D So from the documentation of both MySQL, atol (from stdlib) and =0D NSNumber, I don't understand why there should be a problem for integers =0D= in the 2147483647 to 9223372036854775807 range.=0D Maybe I'm also missing something here???=0D =0D =0D I'm sorry to be a bit untrusty... but can you confirm the problem (then =0D= I'll know for sure that I am missing something):=0D - - You have a BIGINT column type in you retrieved table.=0D - - It contains a number in the range 2147483647 to 9223372036854775807.=0D= - - When you look at it using ie. mysql it appears Ok.=0D - - BUT if you retrieve the exact same information using the SMySQL =0D framework you get a wrong number.=0D =0D If you can confirm that I properly (or not) understand your remark, =0D I'll try my best to fix the problem (and if I did not understand your =0D= bug report, can you try to explain it in a different way).=0D =0D Thanks for the feedback.=0D =0D Serge.=0D =0D PS: Can you also tell me which version of the framework you are using.=0D= =0D Le mardi, 19 ao=FB 2003, =E0 11:45 Europe/Amsterdam, Lorenz Textor a = =E9crit :=0D =0D > Hi everybody,=0D >=0D > It seems that in the SMySQL framework BigInt data types are limited to = =0D > a max value of 2147483647, while MySQL allows 64 (63) bit integer =0D > values. Does anybody know how to fix that? I think that the [NSNumber = =0D > numberWithLong:atol(theData)]; isn't appropriate for BigInt values, =0D= > but I'm not sure what would be right here...=0D >=0D > Thanks for your help=0D > Lorenz=0D >=0D >=0D > Mysql-cocoa-users mailing list=0D > Mys...@li...=0D > https://lists.sourceforge.net/lists/listinfo/mysql-cocoa-users=0D >=0D >=0D - ----------------------------------------------------=0D Serge Cohen=0D =0D GPG Key ID: 9CBB58FB=0D - ----------------------------------------------------=0D -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE/QgmO5EPeG5y7WPsRAtmJAJwMZ0xRFJoSbe0OfyiQxjs6uvzanwCgjWIm OPsZh3HkJ6dU+58v+mQf7Ck=3D =3D4BO1 -----END PGP SIGNATURE----- |
|
From: Lorenz T. <lo...@te...> - 2003-08-20 20:34:59
|
Hi Serge, Thank you for your quick answer! I'm using an old version, but I have checked the current version and it=20= seems to use the same method to get the numeric values. The field is of type BigInt and not unsigned, and the value is showed=20 correctly in other tools. If I open the table in my app, it shows=20 always 2147483647 for values greater than this. I've tested it also=20 with your MySQL Display app to be sure that it it is not an error of my=20= app - with the same result. Please tell me if I should test it with the newest version of the=20 framework too! It's not that important, so look at it only if you have=20= the time... I'll also look at it, but I don't understand enough of this=20= things (can it be a problem of the method numberWithLong: ?). Thanks very much for your work on the framework, it's really great! Cheers, Lorenz On Tuesday, Aug 19, 2003, at 13:27 Europe/Rome, Serge Cohen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi > > If I understand properly the MySQL documentation, we have the=20 > following sizes for integer storage: > > - - SMALLINT : 16 bits (short int in C). > - - MEDIUMINT : 24 bits (inexistent in C). > - - INT or INTEGER : 32 bits (int in C). > - - BIGINT : 64 bits (long int in C). > > So I don't see why the atol function should not work properly for=20 > integers in the range -9223372036854775808 to 9223372036854775807=20 > (though I guess it will not be happy if you use UNSIGNED BIGINT, which=20= > are corresponding to unsigned long int... which atol can not produce,=20= > you will get unexepected result with UNSIGNED BIGINT >=20 > 9223372036854775807)... > > So from the documentation of both MySQL, atol (from stdlib) and=20 > NSNumber, I don't understand why there should be a problem for=20 > integers in the 2147483647 to 9223372036854775807 range. > Maybe I'm also missing something here??? > > > I'm sorry to be a bit untrusty... but can you confirm the problem=20 > (then I'll know for sure that I am missing something): > - - You have a BIGINT column type in you retrieved table. > - - It contains a number in the range 2147483647 to=20 > 9223372036854775807. > - - When you look at it using ie. mysql it appears Ok. > - - BUT if you retrieve the exact same information using the SMySQL=20 > framework you get a wrong number. > > If you can confirm that I properly (or not) understand your remark,=20 > I'll try my best to fix the problem (and if I did not understand your=20= > bug report, can you try to explain it in a different way). > > Thanks for the feedback. > > Serge. > > PS: Can you also tell me which version of the framework you are using. > > Le mardi, 19 ao=FB 2003, =E0 11:45 Europe/Amsterdam, Lorenz Textor a = =E9crit=20 > : > >> Hi everybody, >> >> It seems that in the SMySQL framework BigInt data types are limited=20= >> to a max value of 2147483647, while MySQL allows 64 (63) bit integer=20= >> values. Does anybody know how to fix that? I think that the=20 >> [NSNumber numberWithLong:atol(theData)]; isn't appropriate for BigInt=20= >> values, but I'm not sure what would be right here... >> >> Thanks for your help >> Lorenz >> >> >> Mysql-cocoa-users mailing list >> Mys...@li... >> https://lists.sourceforge.net/lists/listinfo/mysql-cocoa-users >> >> > - ---------------------------------------------------- > Serge Cohen > > GPG Key ID: 9CBB58FB > - ---------------------------------------------------- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (Darwin) > > iD8DBQE/QgmO5EPeG5y7WPsRAtmJAJwMZ0xRFJoSbe0OfyiQxjs6uvzanwCgjWIm > OPsZh3HkJ6dU+58v+mQf7Ck=3D > =3D4BO1 > -----END PGP SIGNATURE----- > > --=20 lorenz textor ** sh ** eigerstrasse 21 8200 schaffhausen tf 052 - 624 27 91 ** ticino ** via delle scuole 41 6963 pregassona tf 091 - 940 20 57 ** mobile 076 - 531 71 74 email lo...@te... |
|
From: Serge C. <ser...@us...> - 2003-08-21 02:17:13
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Lorenz;
Following your last mail, I just tried to understand what I was=20
missing... and I found it (meaning we might be halfway to solving the=20
problem)...
I've wrote a small program to check the size of the different integer=20
types on MacOSX :
#include <stdio.h>
int main(int argc, char **argv)
{
printf("short : %d, int : %d, long : %d, long* : %d, long long : %d,=20=
void* : %d\n",
sizeof(short),sizeof(int), sizeof(long), sizeof(long *),=20
sizeof(long long), sizeof(void*));
return 0;
}
if you compile it (gcc -o sizetst sizes.c), and run it (sizetst), you=20
get the memory size of these types:
short : 2, int : 4, long : 4, long* : 4, long long : 8, void* : 4
^^^^^^^^
And then I realised that long was indeed (as int) a 32 bit integer, to=20=
have a 64bit integer one need to use long long...
SO to correct the list I've sent in my last time, one should have=20
indeed:
* SMALLINT : 16 bits (short int in C).
* MEDIUMINT : 24 bits (inexistent in C).
* INT or INTEGER : 32 bits (int in C).
* BIGINT : 64 bits (long long in C) -- was long int in the previous=20
(wrong) list --.
So now that I've understand what the problem is, I still have to find a=20=
way to correct that... The problem being that I don't know any function=20=
in C which is able to parse an integer into a long long... (and I don't=20=
manage to find my Kernigam & Richie in my library...).
As soon as I find the solution, I'll post it here, and correct the=20
framework.
Serge.
PS: indeed I also have to thank you for the MySQL front-end you are=20
maintaining, it is very useful.
Le mercredi, 20 ao=FB 2003, =E0 22:18 Europe/Amsterdam, Lorenz Textor a=20=
=E9crit :
> Hi Serge,
>
> Thank you for your quick answer!
>
> I'm using an old version, but I have checked the current version and=20=
> it seems to use the same method to get the numeric values.
>
> The field is of type BigInt and not unsigned, and the value is showed=20=
> correctly in other tools. If I open the table in my app, it shows=20
> always 2147483647 for values greater than this. I've tested it also=20
> with your MySQL Display app to be sure that it it is not an error of=20=
> my app - with the same result.
>
> Please tell me if I should test it with the newest version of the=20
> framework too! It's not that important, so look at it only if you have=20=
> the time... I'll also look at it, but I don't understand enough of=20
> this things (can it be a problem of the method numberWithLong: ?).
>
> Thanks very much for your work on the framework, it's really great!
> Cheers,
> Lorenz
>
- ----------------------------------------------------
Serge Cohen
GPG Key ID: 9CBB58FB
- ----------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
iD8DBQE/Q/z05EPeG5y7WPsRApFTAKCoydRlZ15rAI2S1hxL3qK1aCmlvwCggJas
QIf/mOa9xU17KgI4agoewHE=3D
=3DR9n2
-----END PGP SIGNATURE-----
|
|
From: Serge C. <ser...@us...> - 2003-08-21 10:52:50
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Lorenz;
I've fixed the BIGINT issue.
Thanks for your testing perseverance. I'll join the diff on the latest=20=
version of the sources:
All version branches are corrected in CVS (version 1. -> 1.0.1, 2.1.0 -=20=
-> 2.1.1 and 2.2.0 -> 2.2.1).
I will shortly release the sources and binary package for the corrected=20=
version 2.2.1.
Unless you're using version 1. for yourself, I will not release file=20
package of this one (version 2.2. has a script to make the packages...=20=
I have to do things by hand for version 1 + I'm really hoping nobody=20
uses version 1 anymore).
Still, if you use version 1, and not using CVS, I can send you the=20
corrected sources for it.
Serge.
PS: I've tried both strtoll and strtoq.... despite its name strtoll is=20=
NOT ok for long long (make a 32bit truncation of the result), so at the=20=
end only strtoq can do what we wanted.
PPS: I'll try to check if their is a way to know if the field retrieved=20=
is unsigned, in which case I will adapt the code to also handle the=20
unsigned int and bigint. If someone knows how to do that... please=20
spear me the search by myself (enlighten me... :-).
diff --context=3D3 -r1.3 MCPResult.m
*** MCPResult.m 16 Jan 2003 12:18:23 -0000 1.3
- --- MCPResult.m 21 Aug 2003 06:25:51 -0000
***************
*** 257,272 ****
}
else {
char *theData =3D =
calloc(sizeof(char),theLengths[i]+1);
memcpy(theData, theRow[i],theLengths[i]);
theData[theLengths[i]] =3D '\0';
switch (theField[i].type) {
case FIELD_TYPE_TINY:
case FIELD_TYPE_SHORT:
- - case FIELD_TYPE_LONG:
case FIELD_TYPE_INT24:
case FIELD_TYPE_LONGLONG:
! theCurrentObj =3D [NSNumber=20
numberWithLong:atol(theData)];
break;
case FIELD_TYPE_DECIMAL:
case FIELD_TYPE_FLOAT:
- --- 257,275 ----
}
else {
char *theData =3D =
calloc(sizeof(char),theLengths[i]+1);
+ char *theUselLess;
memcpy(theData, theRow[i],theLengths[i]);
theData[theLengths[i]] =3D '\0';
switch (theField[i].type) {
case FIELD_TYPE_TINY:
case FIELD_TYPE_SHORT:
case FIELD_TYPE_INT24:
+ case FIELD_TYPE_LONG:
+ theCurrentObj =3D =
[NSNumber numberWithLong:atol(theData)];
+ break;
case FIELD_TYPE_LONGLONG:
! theCurrentObj =3D [NSNumber=20
numberWithLongLong:strtoq(theData, &theUselLess, 0)];
break;
case FIELD_TYPE_DECIMAL:
case FIELD_TYPE_FLOAT:
Le mercredi, 20 ao=FB 2003, =E0 22:18 Europe/Amsterdam, Lorenz Textor a=20=
=E9crit :
> Hi Serge,
>
> Thank you for your quick answer!
>
> I'm using an old version, but I have checked the current version and=20=
> it seems to use the same method to get the numeric values.
>
> The field is of type BigInt and not unsigned, and the value is showed=20=
> correctly in other tools. If I open the table in my app, it shows=20
> always 2147483647 for values greater than this. I've tested it also=20
> with your MySQL Display app to be sure that it it is not an error of=20=
> my app - with the same result.
>
> Please tell me if I should test it with the newest version of the=20
> framework too! It's not that important, so look at it only if you have=20=
> the time... I'll also look at it, but I don't understand enough of=20
> this things (can it be a problem of the method numberWithLong: ?).
>
> Thanks very much for your work on the framework, it's really great!
> Cheers,
> Lorenz
>
>
- ----------------------------------------------------
Serge Cohen
GPG Key ID: 9CBB58FB
- ----------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
iD8DBQE/RGsx5EPeG5y7WPsRAhdVAKDSofXJ7ALF3a1Jqv3nwykO70baOACfTYJf
US/yzmBcwXEsCZturGRIrXE=3D
=3DOtYY
-----END PGP SIGNATURE-----
|
Thanks for helping keep SourceForge clean.
X