it takes two to tango but MISRA and Keil do not make good partners.
OK I have the following typedef signed char int8_t; typedef unsigned char uint8_t; the above to avoid depending on the compiler re (un)signed typedef char mchar_t; // auxilary for MISRA and strcpy
Ok strcpy (xxx..... gives no error if char xxx.... mchar_t xxx..... but gives rerror for both int8_t xxx... uint8_t xxx..
Nothing to do with either Keil or MISRA, actually.
Passing either signed or unsigned char to a function working on plain char is wrong. At the very least, you have to apply a cast. And you may well have to instrument that cast (e.t. with a /*lint ... */ comment) to get it past a MISRA checker.
Nothing to do with either Keil or MISRA, actually. oh? methinks Keil, if I check the "plain char is signed" box there should, as far as the compiler is concerned, be no difference between 'char' and 'signed char'
At the very least, you have to apply a cast. And you may well have to instrument that cast (e.t. with a /*lint ... */ comment) to get it past a MISRA checker.
which will result in: Use of modifier or type '.....' outside of a typedef [MISRA 2012 Directive 4.6, advisory]
you can fill your code with /*lint ... */ comments but, e.g. strcpy should accept (un)signed depending on the checkbox.
BTW was "plain char is signed" as a choce there in the original C, my ancient book stated that 'char' is signed
there should, as far as the compiler is concerned, be no difference between 'char' and 'signed char' That's not actually correct. There really are three types named char: signed, unsigned and plain. The latter is required to be very similar to one of the two others, but it's not the same.
Use of modifier or type '.....' outside of a typedef [MISRA 2012 Directive 4.6, advisory] If you cast to char *: quite possibly. A cast to something like your (mchar_t *) should work, though. You will get a pointer-to-pointer cast, though.
I don't think MISRA ever really expected anybody to use the standard C library string functions. Remember it's orginally an automotive industry standard. There's really not that much use for printed characters in that field, much less for principally unbounded, zero-terminated strings. I don't think I've used strcpy() at work more than twice in 10 years. It's come to the point where I've actually forgotten the finer details of printf() and scanf() format specifier....
my ancient book stated that 'char' is signed Then it may not actually be sufficiently ancient, or not sufficiently correct. ;-)
It was originally never specified whether plain char is signed or not --- the distinction would have been largely irrelevant at the time, because characters were, for all practical intents and purposes, limited to ASCII, i.e. 7 bits. By the time of the first C standard, enough implementations and code existed making either assumption that neither stood a chance of making it into the official version. That's why we have the three types of char, instead.
It's come to the point where I've actually forgotten the finer details of printf() and scanf() format specifier.... so have I, but I dumped into this place where strcpy etc (fortunately not printf) is sprinkled as heavy as spices on an indian dish.
we can argue till the cows come home re whether char chould be equivalent to one of the two specifics, mchar_t takes care of it a lot easier than 2743 lint exceptions. I still think it should work, but the horse is dead so let's not beat on it.