Why can't Integer be negative?

[Ron Siemens]

I've been using BNFC for a while, got pretty far with my Grammar.  All of a sudden I had need for some negative numbers in my specifications.  To my surprise, Integer is only positive!  Why?!

Then I looked at the sample C language spec and even the unsigned types are positive only - weird!

If I make my own token to support negative values

token Integer ('-')? ["123456789"] digit*;

The generated code now has a "char *" for Integer instead of int.  What a mess!  Isn't there a simpler way to make the built-in "Integer" support negative numbers?  That should have been fixed ages ago, no?

[Ron Siemens]

I mean the non-unsigned types:

token Unsigned ["123456789"] digit * ('u'|'U');

token Long ["123456789"] digit * ('l'|'L'); 

token UnsignedLong ["123456789"] digit * (('u''l')|('U''L'));

https://github.com/BNFC/bnfc/blob/master/examples/C/C.cf

[Ron Siemens]

Doc mentions this:

>These types are hard-coded and cannot be value types of rules:

• Integer: sequence of digits, e.g. 123445425425436'

>Precise definitions are given in the LBNF report.

What is this LBNF report?  Maybe this other documentation which says:

>Each token type is implemented by a newtype in Haskell, as a String in Java, and as a typedef to char* in C etc.

I am using C, so that's why my new Integer token is now a "char *"!  There's no way I can make it an int to keep my code compatible with the built-in Integer token?

Very frustrating...

[Ron Siemens]

After some snooping around, I realized this isn't as "hard-coded" as it seemed.  I changed the definition in the output lex file, before generating my code.