Message ID | 20191024155327.1095907-1-Valdis.Kletnieks@vt.edu (mailing list archive) |
---|---|
Headers | show |
Series | staging: exfat: Clean up return codes | expand |
On Thu, 2019-10-24 at 11:53 -0400, Valdis Kletnieks wrote: > The code had its own non-standard FFS_FOO return codes. Go through > and convert them all the kernel standard -EFOO codes. > > Valdis Kletnieks (15): > staging: exfat: Clean up return codes - FFS_FULL > staging: exfat: Clean up return codes - FFS_NOTFOUND > staging: exfat: Clean up return codes - FFS_DIRBUSY > staging: exfat: Clean up return codes - FFS_PERMISSIONERR > staging: exfat: Clean up return codes - FFS_NAMETOOLONG > staging: exfat: Clean up return codes - FFS_FILEEXIST > staging: exfat: Clean up return codes - FFS_INVALIDPATH > staging: exfat: Clean up return code - FFS_MEMORYERR > staging: exfat: Clean up return codes - FFS_FORMATERR > staging: exfat: Clean up return codes - FFS_MEDIAERR > staging: exfat: Clean up return codes - FFS_EOF > staging: exfat: Clean up return codes - FFS_INVALIDFID > staging: exfat: Clean up return codes - FFS_ERROR > staging: exfat: Clean up return codes - remove unused codes > staging: exfat: Clean up return codes - FFS_SUCCESS All well and good, but does converting the error code from positive to negative have any impact on any of the code paths that use these return values? if (error > 0) vs if (error < 0) ? If you've gone through all the return tests, then it would be nice to say so.
On Thu, 24 Oct 2019 09:23:24 -0700, Joe Perches said: > All well and good, but does converting the error code from > positive to negative have any impact on any of the code > paths that use these return values? > > if (error > 0) > vs > if (error < 0) I was keeping an eye open for that, and didn't see any. An interesting case is the FFS_EOF patch, which fixes an actual bug. If you did a read for length 0, it would return FFS_EOF (==15) - which would be interpreted as the number of bytes returned by read().