Hide Forgot
Description of problem: PString Mid() tries to detect signed integer overflow, but the test is 'undefined behaviour' and gcc happily optimizes it out: PString PString::Mid(PINDEX start, PINDEX len) const { if (len <= 0 || start < 0) return Empty(); if (start+len < start) // Beware of wraparound ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Recent gcc optimizes the above to if (len < 0) return operator()(start, P_MAX_INDEX); else return operator()(start, start+len-1); } This breaks (at least) Ekiga's SIP. Version-Release number of selected component (if applicable): ptlib-2.10.11-1.fc29.x86_64 How reproducible: always Steps to Reproduce: 1. Setup 2 computers with Ekiga on each 2. run ekiga -d 8 on each computer 3. try to call the 2nd computer using sip:IP_address Actual results: The 2nd Ekiga ignores the call, debug output contains information about invalid version of SIP packet: SIP Invalid version (0) received on udp$x.x.x.x:5060<if=udp$*:5060> Expected results: The 2nd Ekiga should ring. Additional info: A quick and dirty workaround would be adding -fwrapv to gcc options.
Could you try to replace > if (start+len < start) // Beware of wraparound by > if (len == P_MAX_INDEX || start+len < start) // If open ended or check for wraparound and test whether it works?
Or change it to 'if (start > INT_MAX - len)'
Oh but it's not an int. So then: if (start > std::numeric_limits<PINDEX>::max() - len)
Both first if (len == P_MAX_INDEX || start+len < start) // If open ended or check for wraparound and the second #include <limits> if (start > std::numeric_limits<PINDEX>::max() - len) work. OTOH I'm not sure the first test is entirely valid in case of a generic library like this. len can be a bit less than P_MAX_INDEX (it's just an arbitrary limit) and still cause the "start + len - 1" to fail. The second test guarantees that start <= max - len and thus start + len - 1 < max. Thanks for looking into this.
My suggestion in comment #2 is simply from what latest upstream uses. If we need to propose something better to upstream, I would need your help in order to do so.
Sorry, I meant comment #1 rather comment #2.
ekiga-4.0.1-44.fc30 ptlib-2.10.11-3.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c5e3dc44ba
Right. I just wasn't aware that the ptlib version used by Ekiga is 7+ years old.
ekiga-4.0.1-44.fc30, ptlib-2.10.11-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c5e3dc44ba
ekiga-4.0.1-44.fc30, ptlib-2.10.11-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.