From: Arvind Yadav > Sent: 23 July 2016 19:06 > IS_ERR_VALUE() assumes that its parameter is an unsigned long. > It can not be used to check if an 'unsigned int' reflects an error. > As they pass an 'unsigned int' into a function that takes an > 'unsigned long' argument. This happens to work because the type > is sign-extended on 64-bit architectures before it gets converted > into an unsigned type. > > However, anything that passes an 'unsigned short' or 'unsigned int' > argument into IS_ERR_VALUE() is guaranteed to be broken, as are > 8-bit integers and types that are wider than 'unsigned long'. > > It would be nice to any users that are not passing 'unsigned int' > arguments. Isn't that a load of bollocks??? It is certainly very over-wordy. IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4096) Assuming sizeof (short) == 2 && sizeof (int) == 4 && sizeof (long) == 8. 'signed char' and 'signed short' are first sign extended to 'signed int'. 'unsigned char' and 'unsigned short' are first zero extended to 'signed int'. 'signed int' is sign extended to 'signed long'. 'signed long' is converted to 'unsigned long' treating the bit-pattern as 'unsigned long'. 'unsigned int' is zero extended to 'unsigned long'. It is probably enough to say that on 64bit systems IS_ERR_VALUE() of unsigned int is always false because the 32bit value is zero extended to 64 bits. A possible 'fix' would be to define IS_ERR_VALUE() as: #define IS_ERR_VALUE(x) unlikely(sizeof (x) > sizeof (int) ? (x) > (unsigned long)-MAX_ERRNO : (x) > (unsigned int)-MAX_ERRNO) However correct analysis of every case might show up real errors. So a compilation warning/error might be more appropriate. David -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
