Inconsistent return value semantics in RTCM3 decoding functions

[Cyfarw9dd]

RTKLIB version: 2.4.2 p13

Using Language: C

Hello, I've identified a potential issue in the RTCM3 decoding functions that may lead to misunderstandings and unexpected behavior. The problem lies in the inconsistent return value semantics between decode_msm7 and other functions like input_rtcm3 and input_rtcm3f.

Problem:

1. In decode_msm7, a successful decoding (when sync is true) returns 0:

return sync ? 0 : 1;

2. However, in input_rtcm3f, the function expects a non-zero return value to indicate successful decoding:

if ((ret=input_rtcm3(rtcm,(unsigned char)data))) return ret;

3. This inconsistency means that even when decode_msm7 successfully decodes a message, input_rtcm3f continues processing instead of returning immediately.

4. Additionally, input_rtcm3 also returns 0 in various error cases(like the checksum), further complicating the issue.

Proposed Solution: Modify the return value of decode_msm7 from sync ? 0 : 1 to sync ? 1 : 0. This change would use 1 as the success code, aligning with the expected behavior in input_rtcm3f.

I've tested this change with messages 1077, 1097, and 1127, and it works well.

This modification would improve code consistency and prevent potential misunderstandings or bugs in the decoding process.

Would you agree with this change? If so, I can prepare a pull request with the necessary modifications.

[yydgis]

you misunderstood the return value, ret = 1 => that is the complete observation message fone epoch (it only return true with the last observation message of one epoch with sync==0), of course, this will cause some issues, if the last message for one epoch of observation with sync==0 is missed. ret = 2 => eph message ret = 5 => station related message ... Yudan

…

On Thu, Sep 5, 2024 at 6:57 PM Cyfarw9dd ***@***.***> wrote: *RTKLIB version: 2.4.2 p13* *Using Language: C* Hello, I've identified a potential issue in the RTCM3 decoding functions that may lead to misunderstandings and unexpected behavior. The problem lies in the inconsistent return value semantics between decode_msm7 and other functions like input_rtcm3 and input_rtcm3f. Problem: 1. In decode_msm7, a successful decoding (when sync is true) returns 0: return sync ? 0 : 1; 2. However, in input_rtcm3f, the function expects a non-zero return value to indicate successful decoding: if ((ret=input_rtcm3(rtcm,(unsigned char)data))) return ret; 3. This inconsistency means that even when decode_msm7 successfully decodes a message, input_rtcm3f continues processing instead of returning immediately. 4. Additionally, input_rtcm3 also returns 0 in various error cases(like the checksum), further complicating the issue. Proposed Solution: Modify the return value of decode_msm7 from sync ? 0 : 1 to sync ? 1 : 0. This change would use 1 as the success code, aligning with the expected behavior in input_rtcm3f. I've tested this change with messages 1077, 1097, and 1127, and it works well. This modification would improve code consistency and prevent potential misunderstandings or bugs in the decoding process. Would you agree with this change? If so, I can prepare a pull request with the necessary modifications. — Reply to this email directly, view it on GitHub <#754>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6QBIYPFVRDDSE62ATCYD3ZVEDYFAVCNFSM6AAAAABNXUEVDGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGUYDSMRWGYZDKMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Cyfarw9dd]

Thank you for your detailed response. It appears I did indeed misunderstand the meaning of 'sync'. Your explanation has been very helpful in clarifying this concept. I appreciate your time and assistance in addressing this issue.

Best regards,
JianTao