Hi Paul, Good question! But i have no true answer on it. There is also ssize_t in linux. size_t always breaks harmony. I think it is a kind of compromise — they wanted to use maximum of available bits. Explicit type conversions are known to lead to errors; they also mask errors that the compiler might point out. In practice, size_t is very frustrating when you want to please a static analyzer and at the same time keep the code readable and free from numerous explicit type casts. The same sizeof returns the size_t and this is rather inconvenient. Fortunately, in our case, there is no need to get the maximum and the signed int type is quite enough to cover the entire range of possible values. If desired, you can add assertions to eliminate programmer errors and negative values. By the way, pay attention that the underlying function in the discussed code takes the size into a signed variable. Additionally, signed type overflow is undefined behavior. And this feature is used by compilers when optimizing. In particular, when optimizing loops, there is no need to take into account the possibility of variable overflow. LLVM has an excellent article on this subject. As it seems to me, I learned about the appointment of unsigned types from their article, or read somewhere in the discussions of the C standard. In general, it is not so important for me how exactly this code will be fixed. I just shared my opinion. -- Alexander Gabitov >Пятница, 5 марта 2021, 14:35 +03:00 от Paul Fertser <[email protected]>: > >Hi Alexander, > >On Fri, Mar 05, 2021 at 01:52:55PM +0300, Alexander Gabitov via OpenOCD-devel >wrote: >> This is the common mistake! Unsigned types was added for another reason to >> standart. But than their sense was perverted and many programmers start use >> them >> for values that cant be negative. But C standart has integer promoution — all >> arifmetics usually done in int. Just try to change it back to unsigned (in >> this >> function) and you will need several type casts. >How about size_t type then? > >-- >Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! >mailto:[email protected]
_______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
