Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: rbowman Newsgroups: comp.os.linux.setup,comp.os.linux.advocacy,sci.physics Subject: Re: Linux Crashing Date: Sat, 2 Oct 2021 12:46:21 -0600 Lines: 35 Message-ID: References: <8j29lg5kteuqhn9o9ophsgfp7afi7o2894@4ax.com> <68e9lg1q6m6phvi6m7mibhljvib8gdt1hq@4ax.com> <2NH5J.151946$Kv2.4408@fx47.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net Se1NhnK+EQiCzPjLyODaTgbBsVzxnSQG0UhpfyAkerAHzJtOvf Cancel-Lock: sha1:U8VZZuSJxAdQVjMjYyQq7SaTS+s= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 In-Reply-To: Xref: csiph.com comp.os.linux.setup:4604 comp.os.linux.advocacy:595096 sci.physics:833514 On 10/02/2021 02:42 AM, The Natural Philosopher wrote: > Actually it is not unusual to find blocks of code that simply do > nothing, or are never ever executed and CAN never ever be executed. I've seen comments in our source like /* should never get here */ . Makes me wonder why the programmer thought it might. > Many coders and maintainers under pressure simply hack it till it passes > tests, and that may include adjusting conditionals blindly, until it > works.. Leaving conditionals that are either always satisfied or never > satisfied. IDE's have gotten a lot better with little flags that say 'you know that's always going to evaluate to true, don't you?' > And again priogrammers working to a spec mindful of their ps and qs may > introduce error handling code to handle errors than simply cannot > happen, because the data being passed to them has already been validated. > The classic case being error handling designed to prevent buffer > overflow on long strings, when the strings have already been checked for > length by freds code in the input validation section Some of our code is over 20 years old, which inspires a bit of paranoid thinking. It doesn't help that the UI is Motif with callbacks that assume some nugget of information was stuffed into the UserData of a passing widget. It was an interesting time when our customer base migrated from RS6000 to Windows. Binaries generated by the AIX C compiler were extremely forgiving about NULL values and went on with life. Microsoft had no patience whatsoever. You learned that calloc() doesn't always come back with an usable pointer and so forth. I think AIX linked 0x0000 to a bit bucket where you could stick anything.