Having lists and dictionaries as default argument values is a bad
idea, because the same instance of list/dict will be used by all
objects instantiated using such constructor:
def appendItem(itemName, itemList=[]):
itemList.append(itemName)
return itemList
print(appendItem('notebook'))
print(appendItem('pencil'))
print(appendItem('eraser'))
Output:
['notebook']
['notebook', 'pencil']
['notebook', 'pencil', 'eraser']
Change-Id: I83d718ff9c3ff6aef47930f38d7f50424f9b880f
The bug that was attempted to be fixed in [1] actually was in the
encoding API - pySim.utils.enc_plmn(). According to 3GPP TS 31.102,
which points to TS 24.008, the three-digit (E)HPLMN shall be encoded
as shown below (ASCII-art interpretation):
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MCC Digit 2 | MCC Digit 1 |
+---+---+---+---+---+---+---+---+
| MNC Digit 3 | MCC Digit 3 |
+---+---+---+---+---+---+---+---+
| MNC Digit 2 | MNC Digit 1 |
+---+---+---+---+---+---+---+---+
while pySim.utils.enc_plmn() would produce the following:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MCC Digit 2 | MCC Digit 1 |
+---+---+---+---+---+---+---+---+
| MNC Digit 1 | MCC Digit 3 |
+---+---+---+---+---+---+---+---+
| MNC Digit 3 | MNC Digit 2 |
+---+---+---+---+---+---+---+---+
Initially the _decoding_ API was correct, but then got changed in
[1] to follow buggy pySim's encoding API. As a result, a (E)HPLMN
programmed with pySim-prog.py would look correct if verified by
pySim-read.py, but the actual file content would be wrong.
This situation shows that our 'program-read-match' build verification
approach alone is insignificant. The lack of unit test coverage,
at least for the core parts of the project, makes it possible to have
symmetrical bugs in both encoding and decoding API parts unnoticed.
This problem was found while trying to enable dead unit tests in [3].
Change [1] that introduced a symmetrical bug is reverted in [2].
Change-Id: Ic7612502e1bb0d280133dabbcb5cb146fc6997e5
Related: [1] I799469206f87e930d8888367890babcb8ebe23a9
Related: [2] If6bf5383988ad442e275efc7c5a159327d104879
Related: [3] I4d4facfabc75187acd5238ff4d0f26022bd58f82
This reverts commit bdf3d3597b, which
broke pySim.utils.dec_mnc_from_plmn(). According to 3GPP TS 31.102,
which points to TS 24.008, the three-digit EHPLMN shall be encoded
as shown below (ASCII-art interpretation):
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| MCC Digit 2 | MCC Digit 1 |
+---+---+---+---+---+---+---+---+
| MNC Digit 3 | MCC Digit 3 |
+---+---+---+---+---+---+---+---+
| MNC Digit 2 | MNC Digit 1 |
+---+---+---+---+---+---+---+---+
So the original implementation was correct, and we even had a unit
test for it. Most likely, the SIM card itself was programmed
incorrectly?
Makes 'testDecMNCfromPLMN_threeDigitMNC' pass again.
Change-Id: If6bf5383988ad442e275efc7c5a159327d104879
As it turns out, we had this set of unit tests since 2018, but
so far they were not executed during the build verification.
Let's fix this:
* run unittest in discovery mode for all files in 'tests/' (commented out);
* rename this file, so it can be automatically detected and executed;
* properly import the API to be tested.
Currently 2 out of 16 unit tests are failing, so we need to get
them passing first and then uncomment the unittest execution.
Change-Id: I4d4facfabc75187acd5238ff4d0f26022bd58f82
This commit fixes two problems (found by semgrep):
* "'foo' and 'bar' in list" is incorrect, because it's interpreted
as "'foo' and ('bar' in list)". Strings with a non-zero length
evaluate to True, thus it's True if at least 'bar' is present.
* Copy-pasted 'E-UTRAN NB-S1' checked two times.
The first condition is redundant, and the whole block can be
re-implemented using two independent 'if' statements.
Change-Id: Iceb66160cfb571db8879d3810c55d252c763d320
Vadim Yanitskiy