Bug #76409 | Documentation state that my_ulonglong mysql_affected_rows() returns -1 | ||
---|---|---|---|
Submitted: | 20 Mar 2015 15:16 | Modified: | 31 Mar 2015 15:37 |
Reporter: | Richard Haven | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Connector / C Documentation | Severity: | S3 (Non-critical) |
Version: | OS: | Any | |
Assigned to: | Paul DuBois | CPU Architecture: | Any |
Tags: | documentation, my_ulonglong, mysql_affected_rows |
[20 Mar 2015 15:16]
Richard Haven
[31 Mar 2015 15:22]
Paul DuBois
I will add this to the discussion at http://dev.mysql.com/doc/refman/5.0/en/c-api-data-structures.html: Some functions that return a row count using this type return -1 as an unsigned value to indicate an error or exceptional condition. You can check for -1 by comparing the return value to (my_ulonglong)-1 (or to (my_ulonglong)~0, which is equivalent).
[31 Mar 2015 15:28]
Paul DuBois
That's basically the same language as is found in the mysql_affected_rows() page, which also indicated how that function can return -1 even though the return type is unsigned. It returns -1 as an unsigned number.
[31 Mar 2015 15:31]
Richard Haven
With all due respect, an "unsigned" -1 is sloppy. Give the actual value rather than depending on an unintuitive side-effect of how compilers evaluate bits.
[31 Mar 2015 15:37]
Paul DuBois
From mysql.cc: else if (mysql_affected_rows(&mysql) == ~(ulonglong) 0) which is equivalent to (my_ulonglong)-1. The expressions as stated in the docs are what is intended for use.