2
0
mirror of https://opendev.org/x/pyghmi synced 2025-01-15 04:07:48 +00:00

Workaround likely spec deviations and fix parsing

For one, was doing UTF-8, though the encoding strictly speaking
per speac should be ISO-8859-1.  Corrected that mistake.  Also
workaround an issue when FRU may be programmed with 0x0 or 0xff
bytes to terminate, or spaces.  The spec actually doesn't speak
to a strategy to pad strings (presumably because they assumed
implementation would avail itself of the capacity for variable
strings and not need to deal with silly fixed length fields).
Handle this by trimming out trailing spaces, 0x0, or 0xff.  This
strictly speaking violates the spec if they want to use one or more
ÿ to end a field, but will take the risk that no one actually would
want to do that.

Change-Id: I7d7e3aa9f3fd2b1e1af75f98cabd49ca374755c0
This commit is contained in:
Jarrod Johnson 2015-10-23 15:45:50 -04:00
parent e96bd8f67c
commit 3411537228

View File

@ -214,9 +214,16 @@ class FRU(object):
# return it as a bytearray, not much to be done for it
return retinfo, newoffset
elif currtype == 3: # text string
if lang == 0:
# Sometimes BMCs have FRU data with 0xff termination
# contrary to spec, but can be tolerated
# also in case something null terminates, handle that too
# strictly speaking, \xff should be a y with diaeresis, but
# erring on the side of that not being very relevant in practice
# to fru info, particularly the last values
retinfo = retinfo.rstrip('\xff\x00 ')
if lang in (0, 25):
try:
retinfo = retinfo.decode('utf-8')
retinfo = retinfo.decode('iso-8859-1')
except UnicodeDecodeError:
pass
else: