I think that flower_packet:ofp_port/1 is really not one but two functions: ofp_name_to_port/1 and ofp_port_to_name/1. That is: the caller always knows whether it prefers names or numbers on the return value, but it may not know exactly what type of parameter it is passing in.
Practically speaking: If client code passes in 16#ffffe as a port then flower is going to crash, for example in encode_match(), because it will call ofp_port() which converts 16#fffe to the atom local and then tries to use that as an integer with the bit syntax.
I have changed this locally and it should filter up to Tobbe's branch soon. I wanted to open an issue so that you can say if it sounds like the wrong idea, or otherwise know the reason when the change filters in.
This is the backwards-compatible way that I wrote the change for now:
Howdy!
I think that
flower_packet:ofp_port/1
is really not one but two functions:ofp_name_to_port/1
andofp_port_to_name/1
. That is: the caller always knows whether it prefers names or numbers on the return value, but it may not know exactly what type of parameter it is passing in.Practically speaking: If client code passes in
16#ffffe
as a port then flower is going to crash, for example inencode_match()
, because it will callofp_port()
which converts16#fffe
to the atomlocal
and then tries to use that as an integer with the bit syntax.I have changed this locally and it should filter up to Tobbe's branch soon. I wanted to open an issue so that you can say if it sounds like the wrong idea, or otherwise know the reason when the change filters in.
This is the backwards-compatible way that I wrote the change for now:
and I made all encoding functions use
ofp_name_to_port()
instead ofofp_port()
to guarantee that they get an integer result.