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
switch.p4's bmv2 JSON config file, for example, has several header_types that are repeated 2 or 3 times. I am not sure, but I think this occurs when more than one header has the same type, e.g. if there is an inner IPv4 header and an outer IPv4 header defined with the same type.
The waste of space in the bmv2 JSON file is not my primary concern here. In the "headers" section, the "header_type" is given as a name, not an id, so this means that bmv2 code must have a way to look up the header_type by name, not id. There are other memory corruption issues when there are name collisions in the JSON config file, e.g. #486
I do not know whether behavioral-model code can cause memory corruption while reading such files, but why risk it?
The text was updated successfully, but these errors were encountered:
switch.p4's bmv2 JSON config file, for example, has several header_types that are repeated 2 or 3 times. I am not sure, but I think this occurs when more than one header has the same type, e.g. if there is an inner IPv4 header and an outer IPv4 header defined with the same type.
The waste of space in the bmv2 JSON file is not my primary concern here. In the "headers" section, the "header_type" is given as a name, not an id, so this means that bmv2 code must have a way to look up the header_type by name, not id. There are other memory corruption issues when there are name collisions in the JSON config file, e.g. #486
I do not know whether behavioral-model code can cause memory corruption while reading such files, but why risk it?
The text was updated successfully, but these errors were encountered: