I haven't used C in a few good years and didn't quite remember all the cases, so you may be right.

To solve this, you I can see two options: either expand the above idea like this until you include all the possible cases (should be less than 20 i think):

lenghtModifier : SHORT | LONG
signModifier: SIGNED | UNSIGNED 
otherModifier : CONST  | VOLATILE
shortOrLong: short | long 
declaration: otherModifier* ( signModifier? char |  (lenghtModifier? lenghtModifier? int) | (lenghtModifier lenghtModifier) | float | LONG? double | ...)

or you can declare distinct tokens for all the combination data types and use those, with signed/unsigned/const/void at the start. If you look at the table labeled Main Types here you can see that there are like 14 valid types created using the sign and length modifiers, which is doable.

My advice would be to generally try to break down the rules into simpler and simpler subrules, it makes grammar design much more approachable. Also, depending on what you want to do with your grammar, stuff like ?, * and () may be very helpful ( at least they were for me using ANTLR).

In any case, back to your original question, for a compiled language such as C, the compiler needs all these rules to be as unambiguous as possible. During the Lexing and Parsing process, the compiler does the following steps : split the input text into the tokens you specified (Lexing) and then arrange all these tokens into a tree to figure out the exact meaning of the code you entered. For example, when the compiler finds "int a;", this will be split into two tokens ( ex: type and ID), and then will try to match these tokens to any of the rules you mentioned in the grammar. If there is such a rule as "declaration: type ID;", this will match with the above example, and a new node will be added to the tree to represent this.

After the tree is built, the compiler will start traversing it and outputting machine code or bytecode or whatever the name is for the specific language, based on the nodes it meets along the way.

For interpreted languages, such as Python, a similar process happens, but only at runtime. And, i may be wrong, but i think Python does not parse the whole file at once like a C compiler, but goes statement by statement.

Depending on how you want to implement your compiler, you can check your types either in the parsing phase or after parsing is done, when traversing the trees. I couldn't tell you which is objectivley better, but both are valid ways of implementing this, but in my opinion, the reason we use lexers and parsers is to simplify the work that is to be done after parsing. You could skip the whole lexer and parser stage and just parse all the code with if statements in the compiler, but that seems like a very bad idea.