You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
grpc-labview's intermediate representation of enum key/value pairs is as follows:
string1=value1;string2=value2;string3=values3
This means that adding an = or ; to your enum string will cause grpc-labview to either corrupt memory or crash. This has been an issue for MeasurementLink because we can't control what our customers add to their enums. If their enums have a = or ; and we call Register Enum Metadata.vi, bad things will happen.
To workaround this issue, MeasurementLink is checking the enum strings before calling Register Enum Metadata.vi and throwing a helpful error if the enum contains an invalid character. However, grpc-labview should really consider using a standard format for the intermediate representation rather than inventing their own. For example, json wouldn't have such restrictions.
I realize that various grpc style guides prohibit special characters like ; and =. This bug is more about recommending that you don't invent your own tokenization code and instead use an industry standard.
AB#2599407
The text was updated successfully, but these errors were encountered:
grpc-labview's intermediate representation of enum key/value pairs is as follows:
string1=value1;string2=value2;string3=values3
This means that adding an
=
or;
to your enum string will cause grpc-labview to either corrupt memory or crash. This has been an issue for MeasurementLink because we can't control what our customers add to their enums. If their enums have a=
or;
and we callRegister Enum Metadata.vi
, bad things will happen.To workaround this issue, MeasurementLink is checking the enum strings before calling
Register Enum Metadata.vi
and throwing a helpful error if the enum contains an invalid character. However, grpc-labview should really consider using a standard format for the intermediate representation rather than inventing their own. For example, json wouldn't have such restrictions.I realize that various grpc style guides prohibit special characters like
;
and=
. This bug is more about recommending that you don't invent your own tokenization code and instead use an industry standard.AB#2599407
The text was updated successfully, but these errors were encountered: