lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #51520] Big endian bug in apps/snmp/snmp_asn1.c


From: Art Heers
Subject: [lwip-devel] [bug #51520] Big endian bug in apps/snmp/snmp_asn1.c
Date: Tue, 25 Jul 2017 12:59:35 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Follow-up Comment #2, bug #51520 (project lwip):

We (Campbell Scientific) are using the Renesas processors, most recently the
RX series, Rx63N, in our measurement and control systems (dataloggers).  Over
the years we have built up our own operating system and at some point a few
years ago gravitated to the LwIP stack.  The Renesas processors (originally
Hitachi) followed Motorola's big endian model, though their more recent
processors can optionally be run as little also.  We have stuck to big endian.
 Renesas does have a development platform that you might want to look into.

As for the code issue, the function could have been written in such a way to
avoid checking BYTE_ORDER by simply calculating what value is locally and then
passing that value back via the pointer at the bottom of the function. 
Instead it chose to use a pointer to value and to use that pointer during the
creation of the value, one byte at a time, and therefore had to know the byte
order of the machine.  It would be better, like you suggest to leave out
BYTE_ORDER altogether by using a local uint32 localvalue, calculate the value
with it, and the at the end do *value = localvalue. 

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?51520>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]