PC-lint / Flexelint rule against plain char

Question

Gimpel Software's PC-lint and Flexelint have a rule "971: Use of 'char' without 'signed' or 'unsigned'", that forbids using the plain char type without specifying signedness.

http://www.gimpel.com/html/pub/msg.txt

I think this is misguided. If char is used as an integer type then it might make sense to specify signedness explicitly, but not when it is used for textual characters. Standard library functions like printf take pointers to plain char, and using signed or unsigned char is a type mismatch. One can of course cast between the types, but that can lead to just the kind of mistakes that lint is trying to prevent.

Is this lint rule against the plain char type wrong?

Answer 1

The messages PC Lint provides in the 900-999 (and 1900-1999 for C++) range are called "Elective Notes" and off by default. They are intended for use if you have a coding guideline that is restrictive in some specific way. You may then activate one or more of these notes to help you find potential violations. I do not think that anyone has activated all the 9xx messages in a real development effort.

You are right about char: It is the use of a byte (almost always) for a real character. However, a char is treated by a C compiler as either signed or unsigned. For C++, char is different from both unsigned char and from signed char.

I many embedded C environments I have worked in it was customary to have a coding rule stating that a plain char is not allowed. That's when this PC Lint message should be activated. Exceptions, like in interfacing with other libraries, had to be explicitly permitted, and then used a Lint comment to suppress the individual message.

Answer 2

I would assume the reason that they chose to force you to pick signed or unsigned is because the C standard does not. The C standard states char, unsigned char, and signed char are three unique types.

gcc for example makes the default signed but that can be modified with the flag -funsigned-char

So IMO I would say no, the rule aginst it is not wrong, it's just trying to tighten up the C spec.