Re: [fossil-users] 64 bit rowid bug?
But i'm just being technically pedantic, so don't take all that too seriously. i see nothing wrong with using sqlite3_int64 everywhere, to be honest, and wouldn't mind adding a patch to the upstream JSON bits which use sqlite3_int64 when compiling for fossil (they already have one such place so that they use fossil_alloc() and fossil_free(), to inherit its die-on-alloc-failure behaviour, which reduces (greatly) the amount of error checking in the fossil JSON bits). Well, looking at the fossil code, int's are use everywhere, except for timestamps and file sizes. I think that would be a good rule for JSON as well. A few related fixes: https://www.fossil-scm.org/index.html/info/f89a32d782 This way, files somewhat bigger than 2Gb or timestamps after 2038 wouldn't be an immediate problem. But transfering a 64-bit pointer or a 64-bit hash value as an integer on JSON, that's asking for trouble! Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
2013/6/15 Richard Hipp d...@sqlite.org: On Fri, Jun 14, 2013 at 8:15 PM, Edward Berner e...@bernerfam.com wrote: Hello, db_last_insert_rowid() is defined in db.c to return an i64, but every use of the function stores the result in an int. I guess it might cause problems - if you created a repository with over 2 billion artifacts. A typical busy project (ex: Tcl, SQLite) accumulates between 1K and 10K artifacts per year. So this probably won't be a problem any time soon. I think the assumption of of less than 2 billion artifacts probably permeates the code, so this might be a really big patch, though. Are you sure it is worth it? Hm, I would suggest to change the return-type from i64 to size_t. On 32-bit systems that would double the maximum number of artifacts, with hardly any impact. See: http://fossil-scm.org/index.html/info/e1cb483a9b Of course, some more internal variables have to change type, but it's a harmless change, and it will mean that on 64-bit systems there simply will be no limit any more. The only hassle that needed to be solved first was 64-bit support for JSON on win64, but that's done now. Richard, Stephan, how do you feel about this? Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
On Thu, Jun 20, 2013 at 4:01 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote: Hm, I would suggest to change the return-type from i64 to size_t. On 32-bit systems that would double the maximum number of artifacts, *shiver* i've had nothing but problems when trying to rely on size_t across 32/64-bit portable apps. i recommend going one further and relying on C99's inttypes.h and stdint.h, which define fixed-size integers and their portable printf/scanf modifiers (as you saw when you patched cson). i use them in almost all of my code, even projects which are otherwise 100% C89. There is also a free (BSD) drop-in impl for MS C platforms (since MS doesn't do C99): http://code.google.com/p/msinttypes/ The only hassle that needed to be solved first was 64-bit support for JSON on win64, but that's done now. Careful - JSON itself does NOT specify integer precision, which means that just because fossil can now generate e.g. the value 140, doesn't mean that any given consumer on the other end can read it properly (or even fail predictably). The IETF is (right now) discussing (at length) a formal JSON standard and this topic has come up (i've been following the list chatter), but AFAIK there has been no consensus reached because it is impossible to enforce any given limits on any and all platforms. They can, at best, define how a JSON consumer has to deal with values which fall outside of its limits. Richard, Stephan, how do you feel about this? Personally i'm for inttypes.h and stdint.h, using fixed-size integers, and i've always been well-served by them, but if 100% portability to c89 is of a concern then it's not an option. (i tend to aim for c89 but am relatively ambivalent on the topic.) That said, sqlite3 also uses (long long) in one of its typedefs, though that type is not strict C89 (but is a common extension). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
2013/6/20 Stephan Beal sgb...@googlemail.com: On Thu, Jun 20, 2013 at 4:40 PM, Stephan Beal sgb...@googlemail.com wrote: *shiver* i've had nothing but problems when trying to rely on size_t across 32/64-bit portable apps. Sorry, i should have qualified that a bit better: problems not meaning segfaults and whatnot, but the fact that i can't get a printf() or scanf() to DTRT without explicit casts on one platform or the other. Fixed-size ints and standard format strings patch that all up (with one caveat being that there is no portable 64-bit format string for C_89_). Fossil does it's own printf-like formatting, so whatever solution chosen can be implemented consistantly. size_t is the simplest, with least impact on 32-bit systems. Making everything i64 is possible too, but Richard already remarked on that: Are you sure it is worth it? Careful - JSON itself does NOT specify integer precision, which means that just because fossil can now generate e.g. the value 140, doesn't mean that any given consumer on the other end can read it properly (or even fail I thought that javascript uses 64-bit floating-point for numbers internally, which means that integers up to 153 should be no problem for any compliant implementation. That's a lot more than 132. ! Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
2013/6/20 Richard Hipp d...@sqlite.org: Making this change will only introduce new, real bugs that impact everyday users. Thanks! That's OK with me. But then the question remains why the return-type of db_last_insert_rowid() is not int then? Regards, Jan Nijtmans. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
On Thu, Jun 20, 2013 at 11:12 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2013/6/20 Richard Hipp d...@sqlite.org: Making this change will only introduce new, real bugs that impact everyday users. Thanks! That's OK with me. But then the question remains why the return-type of db_last_insert_rowid() is not int then? It now returns an int, and throws a fatal error if the last rowid() is negative or will not fit into an int. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] 64 bit rowid bug?
Hello, db_last_insert_rowid() is defined in db.c to return an i64, but every use of the function stores the result in an int. That looks like a bug, unless something else is constraining the rowid value. A proper and complete fix seems non-trivial, but in the interim perhaps db_last_insert_rowid() should issue a warning or fail an assertion if the rowid is greater than INT_MAX? -- Edward Berner ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 64 bit rowid bug?
On Fri, Jun 14, 2013 at 8:15 PM, Edward Berner e...@bernerfam.com wrote: Hello, db_last_insert_rowid() is defined in db.c to return an i64, but every use of the function stores the result in an int. I guess it might cause problems - if you created a repository with over 2 billion artifacts. A typical busy project (ex: Tcl, SQLite) accumulates between 1K and 10K artifacts per year. So this probably won't be a problem any time soon. I think the assumption of of less than 2 billion artifacts probably permeates the code, so this might be a really big patch, though. Are you sure it is worth it? That looks like a bug, unless something else is constraining the rowid value. A proper and complete fix seems non-trivial, but in the interim perhaps db_last_insert_rowid() should issue a warning or fail an assertion if the rowid is greater than INT_MAX? -- Edward Berner __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
