x64 integer

[sandeep2501]

Hello,

I have downloaded the latest asn1c code from your branch and the asn1c compiler with specification with x64 integer is giving this error

Value "18446744073709551615" at line 9 is too large for this compiler! Please contact the asn1c author. ASN.1 grammar parse error near line 9 (token "18446744073709551615"): syntax error, unexpected $end

I was going through the "vlm/asn1c" issue list and saw that you have marked this issue as fixed.

asn.1 file was like: DEFINITIONS AUTOMATIC TAGS ::=

BEGIN -- size = 64 bits Id ::= INTEGER (0..18446744073709551615)

-- size = 8 bits
Interface ::= INTEGER (0..255)

-- size = 8 bits
Targeted ::= INTEGER (0..255)

how can I compile huge numbers like this one?

[mouse07410]

I confirm the problem. The issue was fixed and tested on a smaller value: INTEGER (0..9223372036854775807).

@velichkov and @brchiu, what is your take? Theoretically, ASN.1 INTEGER is not limited in size, so any boundary should be OK. Including the one specified above... Or is the issue that the constraints aren't required to support the entire INTEGER range?

Update Looking at this issue, I see that the error message is generated by asn1p_atoi() function:

int
asn1p_atoi(const char *ptr, asn1c_integer_t *value) {
        errno = 0;      /* Clear the error code */

        if(sizeof(*value) <= sizeof(int)) {
                *value = strtol(ptr, 0, 10);
        } else {
#ifdef  HAVE_STRTOIMAX
                *value = strtoimax(ptr, 0, 10);
#elif   HAVE_STRTOLL
                *value = strtoll(ptr, 0, 10);
#else
                *value = strtol(ptr, 0, 10);
#endif
        }

        return errno == 0 ? 0 : -1;
}

I'm a bit confused here: does it mean that asn1c limits support of INTEGER to #define INT64_MAX 9223372036854775807LL at most?

[velichkov]

Hi @sandeep2501, @mouse07410

what is your take? Theoretically, ASN.1 INTEGER is not limited in size, so any boundary should be OK. Including the one specified above...

That's correct.

Or is the issue that the constraints aren't required to support the entire INTEGER range?

It would be nice to support any constrain but that's not so easy.

Looking at this issue, I see that the error message is generated by asn1p_atoi() function: I'm a bit confused here: does it mean that asn1c limits support of INTEGER to #define INT64_MAX 9223372036854775807LL at most?

The asn1c supports any integers through its INTEGER_t type but currently only supports constrains in (-9223372036854775807..9223372036854775806) range (64bit sign integer)

The first problem is that constrain values are stored in asn1c_integer_t type which is defined as intmax_t which is sign 64 bit integer on most platforms. There is uintmax_t type but we can't just swap them as we need to support negative constraints as well. We could try to use INTEGER_t type to store the constrains and implement strtoimax/strtoumax equivalent function that is able to parse bigger values as well some comparison function (<, ==, ...) or find some opensource BigInt implementation with suitable license.

[mouse07410]

We could try to use INTEGER_t type to store the constrains and implement strtoimax/strtoumax equivalent function that is able to parse bigger values as well some comparison function (<, ==, ...) or find some opensource BigInt implementation with suitable license.

If that open source BigInt implementation (GMP library comes to mind as a potential candidate) would be used only by the asn1c compiler, but not by the generated code - then it would be fine.

However, since the constraints probably need to be processed by the generated code as well, I suspect using INTEGER_t and implementing equivalents of strtoimax() and strtoumax() is our best choice.

Also, it is unclear what role/purpose/need would adding "any constraint size" fill. @sandeep2501 what's the practical case for needing such a constraint? Is it, e.g., a file size constraint??? An index in some huge database...? Amount of money we'd get if we implement this...?

What is your opinion?

[sandeep2501]

Hi @mouse07410

Yes, the ID iam trying to decode is the index value of a record. For a time being I have found a work around for this issue. First I generated the code using 9223372036854775806 value. Than in the generated code, I did the changes where it was checking the constraints. I changed the constraint checking from 9223372036854775806 to 18446744073709551615 and it worked fine.

Initially, when I was debugging the issue I also found out it is failing because of strtoimax() and I convert it to strtoumax() as In my ASN grammar file there were no negative values, But when I change it, It start failing in "asn1fix". So i left it there and went for the quick fix

[mouse07410]

@sandeep2501 what would happen if you don't specify the constraint at all? If your index can be, e.g., 9223372036854775806 - why cannot it be, e.g., 9223372036854775807 or 9223372036854775808 or 9223372036854775815 later on?

@velichkov it looks like changing constraint type to INTEGER_t would be a good idea...