Improvement #271

Avoid to set Network Address to negative number

Added by Stefano Lenzi almost 4 years ago. Updated almost 4 years ago.

Status:Closed Start date:11/05/2014
Priority:Immediate Due date:
Assignee:Stefano Lenzi % Done:


Category:zigbee.basedriver Spent time: -
Target version:org.aaloa.zb4osgi.zigbee.basedriver-0.8.0
Has a patch:No Has license agreement signed:No


Since #264 was proposed we should also avoid that negative valus is stored as network address is the ZigBeeNode interface

Related issues

blocks Bug #264: Confusion between signed and unsigned 16bit short address Closed 10/23/2014

Associated revisions

Revision 1088
Added by Stefano Lenzi almost 4 years ago

Added JUnit for testing the issue ( refs #271 )
Fixed the behavior on some constructor ( refs #271 )


#1 Updated by Stefano Lenzi almost 4 years ago

  • Status changed from New to Resolved

It has been fixed with r1087, but before closing this issue we need some JUnit for verifying the code

#2 Updated by Philipp Buluschek almost 4 years ago

In r1087 : the check for negative network address should not be done in the constructor, but rather in the setNetworkAddress method - else somebody might set a new negative value later.

Also, it is not recommended to call overridable methods in the constructor (see eg. Easiest fix: make the class final.

#3 Updated by Stefano Lenzi almost 4 years ago

  • Status changed from Resolved to Closed

The commit r1087 was a simple easy fix. In fact, I move the check inside the setNetworkAddress. Regarding setting the class as final I don't think it is need considered that the class is used only internally by the ZigBee Base Driver while all the other while use the object as ZigBeeNode as defined by the ZigBee Base Driver API, thus they would not have access to the setNetworkAddress(int) method.

Please reopen this bug if you disagree.

Also available in: Atom PDF