rtel wrote on Friday, November 29, 2013:
This is a very subjective thing. Every change we make to please you will upset somebody else, or in this case probably more than one somebody else. I’m sorry we can’t please all of the people all of the time. I have in fact just added in more of these in the latest SVN checkin directly as a result of user feedback that some were missing.
but writing redundand attributes like “signed portBASE”
In that case the ‘signed’ is absolutely not redundant. You have to look at the history of the code. Originally in many ports portBASE_TYPE was a char, and in line with I think every coding standard I have seen, and in MISRA, plain unqualified char types can simply not be used. Probably three quarters of the compilers supported have plain chars unsigned by default (because they are embedded compilers), and the other quarter have then
signed.
where on most 32 and 16 bit platfroms portBASE is signed by default
Would not be better to typedef in portable layer portCHAR (on my port it is already
defined) to char or unsigned char and use this type when string parameter is needed?
Historically this was done, guess what, people complained and it was removed. Now you want them back again, so again my point is being made quite clearly.
Another example: you are using type portSTACK_TYPE to specify stack type parameter type,
but size is not typed (maybe portSIZE_TYPE should be introduced).
The only real place in the code where the size of a type is important is for pointers, and there is a pointer size type for those ports that require it (the ones with eccentric number of bits for the address bus or different memory models).
As it happens - I actually agree with you on a lot of points. If you look at the newer FreeRTOS components that are provided directly by us you will see all types come from stdint.h - and typedefs end with a ‘_t’, like C’s standard size_t. I would like to change the convention used in FreeRTOS itself to match that, but to do so would result in a lot of complaints about backward compatibility being broken (the prototype of all the API functions would change). Still, version 8 will be released as soon as we find time to document it, and as that is a major version number update that would be the time to do it.
Regards.
You used the work most yourself there, which sort of is my point.