I have seen the bug in old code that a new compiler optimization/library fix exposed. I have seen code unload a loadable library and then turn around and call a function in the unloaded library (it worked since the unload was a NOOP), but broke when the vendor removed/fixed the NOOP and made the unload work like it should have always worked. Developers argued with the vendor for *MONTHS* that their code had worked for years and on 3 different unixes (all being lazy and NOOPing). It is not clear to me how anyone is stupid enough to argue that the calls they asked to be unloaded should work after the unload, but they did argue that for months. I have seen fortran code that "worked" for years. The Intel compiler broke it by putting fortran const's in a read-only segment and they were passing a const (in fortran it is not allowed to be changed) into a subroutine and changing it. The professor was yelling at my company for similar reasons (the code has worked for years it cannot be the code, it is this crappy compiler you sold us). I also previously worked for a company that compiled their code with 3 different bought linux compilers, and a SGI and Sun compiler and examined the warnings from all and resolved them and found that warnings on one or the other compiler would flag something and upon examination of the code they often could not understand why the code "appeared" work well enough even with what was clearly a bug in the code. Just because your code "appears" to work in your test case says little or nothing about the code being "perfect". I have found significant bugs that made me question how the code was returning correct results too many times. Never assume that old code is right. there are many ways for it to be wrong and still return correct results until someone else fixes their external code that was allowing your bad code to work. On Thu, Nov 23, 2023 at 5:15 PM Barry <barry@xxxxxxxxxxxxxxxx> wrote: > > > > > On 23 Nov 2023, at 14:18, Ranjan Maitra via users <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > One aspect to note is that the C code (not by me) is from 1988, though last updated in 1997. It is not clear to me if that is a plus (because programmers had the time to be more careful in those days) or a minus (because more sophisticated environments are available now). I do compile with -Wall -pedantic and there are no complaints. However, that does not mean that there can not be some memory leak or something else that has stayed dormant all these years and have surfaced with the changes to Python 3.12. > > Old code is bug free is it? News to me :-) > Schedule pressure was a thing in 1997 as well as every year! > > It is pointless to speculate, just debug what you have in front of you. > > Barry > > -- > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
