This content has been marked as final. Show 6 replies
no. there would be an overhead for the array itself, not for each byte!
but iit will depend on the platform.
still, a 25 bytes overhead per array seems rather big to me.
the platform needs at least the number of elements, but I can't see what can justify so much overhead.
if you get more info from your expert, that would be interesting.
Yes it is for each individual array, sorry for my bad English.
25bytes overhead is something confusing. Someone else told me that, this overhead will be about 4 bytes but I could not found this information in any official documents.
What other information should i get from him ?
Thanks for reply
AFAIK this is not specified. The jcre spec only states the maximum number of array elements, and maybe, the storage size for each element (and I'm even not sure for booleans and object references).
you should ask him on which platform he saw that, and when.
I suspect this overhead information is only known by the javacard OS manufacturer.
You shall expect different values, e.g. jcop, oberthur, gemalto, you-name-it will have different overheads.
I have seen some platforms that have a 7 byte overhead for objects (an array is an object). The size would be 2 bytes and there could be some context information (pointer to the owning context) and the pointer to the object itself.1 person found this helpful
You may be able to infer more of this from the specs but there is definitely an overhead to arrays. You can use a flat array with base offsets etc and let the compiler inline the constants.
byte val = LARGE_ARRAY[(short)(BASE_OFFSET_A1 + OFFSET1)];
Actually, if we will use this approach then offsets will be more than 255 and then we won't be able to index correctly.
Do you have any other suggestions on this please ?
That's not a problem. You can have 32,767 elements in an array and the constants would be shorts. The addition is cast to a short as well. This will allow more than 255 elements to be referenced :)