Unnecessary implicit conversion (may lead to a bug)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Unnecessary implicit conversion (may lead to a bug)

mailing lists
In

afpUnlock(sqlite3_file *, int)

the sharedLockByte is defined as an int (int sharedLockByte = SHARED_FIRST+pInode->sharedByte;) although all other related variables and the following function parameters are defined as unsigned long longs. At least theoretically this can lead to information loss and wrong sharedLockBytes values. If this is also practically the case I do not know.

Regards,
Hartwig


_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Unnecessary implicit conversion (may lead to a bug)

Dan Kennedy-4
On 02/24/2014 05:54 AM, skywind mailing lists wrote:
> In
>
> afpUnlock(sqlite3_file *, int)
>
> the sharedLockByte is defined as an int (int sharedLockByte = SHARED_FIRST+pInode->sharedByte;) although all other related variables and the following function parameters are defined as unsigned long longs. At least theoretically this can lead to information loss and wrong sharedLockBytes values. If this is also practically the case I do not know.

I think it's Ok. (pInode->sharedByte) is always between 0 and
SHARED_SIZE, which is defined as 510. And SHARED_FIRST is (2^30)+2. As
you can't change either of these without creating either an incompatible
file-format or a broken build, it's probably Ok. Does look a bit odd though.

Dan.


_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users