Grasping over the .r1cs documentation r1cs docs the section 2 explicitly tells:

But in the .r1cs file, the values are not stored like that, but as negative numbers instead, taking the header.prime as the max integer.
For example:
For this constrain:

The expected bytes would be:
[xx-xx-xx-xx][01000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
[xx-xx-xx-xx][01000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
[xx-xx-xx-xx][01000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
but in the .r1cs they are stored as
[xx-xx-xx-xx][000000f, 093f5e14, 39170b97, 948e8332, 85d58818, 1b64550b, 829a031e, 1724e6430]
[xx-xx-xx-xx][000000f, 093f5e14, 39170b97, 948e8332, 85d58818, 1b64550b, 829a031e, 1724e6430]
[xx-xx-xx-xx][0100000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
If i substract headers.prime to these bytes, the result is actually the one that is described in the documentation.
Constants are also encoded as positive numbers, for example, taking the constraint
5 + a * b ==> c
The linearCombination will be produced as:
[xx-xx-xx-xx][0500000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
[xx-xx-xx-xx][000000f, 093f5e14, 39170b97, 948e8332, 85d58818, 1b64550b, 829a031e, 1724e6430]
[xx-xx-xx-xx][000000f, 093f5e14, 39170b97, 948e8332, 85d58818, 1b64550b, 829a031e, 1724e6430]
[xx-xx-xx-xx][0100000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
This behavior is not described in the documentation of the .r1cs.
If the explanation i make for this behavior is right (Can be wrong if the reasons of this behavior are others and not just, negative numbers)
I'm proposing myself to modify the .r1cs specification to add the explanation for this fields.
Grasping over the .r1cs documentation r1cs docs the section 2 explicitly tells:
But in the .r1cs file, the values are not stored like that, but as negative numbers instead, taking the header.prime as the max integer.
For example:
For this constrain:
The expected bytes would be:
[xx-xx-xx-xx][01000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
[xx-xx-xx-xx][01000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
[xx-xx-xx-xx][01000000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
but in the .r1cs they are stored as
[xx-xx-xx-xx][000000f, 093f5e14, 39170b97, 948e8332, 85d58818, 1b64550b, 829a031e, 1724e6430]
[xx-xx-xx-xx][000000f, 093f5e14, 39170b97, 948e8332, 85d58818, 1b64550b, 829a031e, 1724e6430]
[xx-xx-xx-xx][0100000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
If i substract headers.prime to these bytes, the result is actually the one that is described in the documentation.
Constants are also encoded as positive numbers, for example, taking the constraint
5 + a * b ==> c
The linearCombination will be produced as:
[xx-xx-xx-xx][0500000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
[xx-xx-xx-xx][000000f, 093f5e14, 39170b97, 948e8332, 85d58818, 1b64550b, 829a031e, 1724e6430]
[xx-xx-xx-xx][000000f, 093f5e14, 39170b97, 948e8332, 85d58818, 1b64550b, 829a031e, 1724e6430]
[xx-xx-xx-xx][0100000, 00000000, 00000000, 00000000, 00000000, 00000000, 00000000]
This behavior is not described in the documentation of the .r1cs.
If the explanation i make for this behavior is right (Can be wrong if the reasons of this behavior are others and not just, negative numbers)
I'm proposing myself to modify the .r1cs specification to add the explanation for this fields.