search

librasn / rasn

A Safe #[no_std] ASN.1 Codec Framework
Other
183 stars 43 forks source link

Getting default value of type not currently possible when implementing codec #211

Closed Nicceboy closed 7 months ago

Nicceboy commented 7 months ago

It seems that default value for types is used as fallback if inner decoding result is empty, e.g.

https://github.com/XAMPPRocky/rasn/blob/2ca6ad88b20c6c8af4c22c622ab2ac2f1850e711/src/de.rs#L236-L244

On same cases codec decoder might want to rise an error if the default is encoded as value when it should be omitted.

It is not possible to create such error if the default value is not accessible, as the default value cannot be known.

Maybe not high priority issue. One way to implement is to add one parameter for each decode_optional* method, if that would be okay.

XAMPPRocky commented 7 months ago

On same cases codec decoder might want to rise an error if the default is encoded as value when it should be omitted.

Is this a meaningful case? Like is there a case where it's better to present an error when presented with a value that matches the default?

Nicceboy commented 7 months ago

When looking the COER encoding rules, there is section:

31.9 In the encoding of a sequence or set type, each component that is marked DEFAULT shall be encoded as absent if its value is identical to the default value.

I am not sure how to handle this on decoder side, but I would assume that it is error if there is default value instead of omitting it.

XAMPPRocky commented 7 months ago

I am not sure how to handle this on decoder side, but I would assume that it is error if there is default value instead of omitting it.

I don't know if I would assume that, an encoder is supposed to omit it, but I feel like it's more intuitive for the decoder to accept, it's not like (correct me if I'm wrong), that we can take advantage of an optimisation here, because in order to know if it's the default value, we have to decode it anyway, and by that point we have already all the work.

Nicceboy commented 7 months ago

I don't know if I would assume that, an encoder is supposed to omit it, but I feel like it's more intuitive for the decoder to accept, it's not like (correct me if I'm wrong), that we can take advantage of an optimisation here, because in order to know if it's the default value, we have to decode it anyway, and by that point we have already all the work.

That is certaintly true from performance point. I am trying to make distinction between OER and COER decoder (OER happily decodes defaults), so that what is left for COER is to strictly validate if the input is produced by COER encoder.

But I don't mind if we just consider more optimisation here. I don't see many use cases why someone would want that error.

XAMPPRocky commented 7 months ago

But I don't mind if we just consider more optimisation here. I don't see many use cases why someone would want that error.

Yeah I think for now, let's leave it, we can still validate COER through our tests. I think is someone can provide a compelling use case, then we can change. Because right now, the other codecs do the same thing where if the value provided is the default, it's just passed along and we don't check.