osmo-tetra/6ab25a3adf55c3c7ff9b1ae58d2...

39 lines
1.6 KiB
Plaintext

{
"comments": [
{
"unresolved": true,
"key": {
"uuid": "25f4334f_02449d18",
"filename": "src/lower_mac/tetra_lower_mac.c",
"patchSetId": 4
},
"lineNbr": 311,
"author": {
"id": 1000004
},
"writtenOn": "2022-09-20T12:18:41Z",
"side": 1,
"message": "again the question why those are signed, i.e. what are the negative values supported to represent?",
"revId": "6ab25a3adf55c3c7ff9b1ae58d24e2d0546a7263",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
},
{
"unresolved": false,
"key": {
"uuid": "e4fd1517_f440d0de",
"filename": "src/lower_mac/tetra_lower_mac.c",
"patchSetId": 4
},
"lineNbr": 311,
"author": {
"id": 1000225
},
"writtenOn": "2022-09-20T13:43:44Z",
"side": 1,
"message": "In some cases (for instance, when a frame cannot be parsed propery), we cannot determine the size of the MAC PDU. In that case, a -1 will be returned. There are also some cases I haven\u0027t explored yet, such as whether an additional PDU can exist after a broadcast. A return value of -1 will lead to the lower mac to not pass any further PDUs to the upper mac for that timeslot. \n\nOffset should be unsigned. Also, it would be more elegant to break inside the loop when a -1 is returned, instead of altering the msg pointers with the negative value. I\u0027ve pushed a revision with these improvements.",
"parentUuid": "25f4334f_02449d18",
"revId": "6ab25a3adf55c3c7ff9b1ae58d24e2d0546a7263",
"serverId": "035e6965-6537-41bd-912c-053f3cf69326"
}
]
}