On 02/06/2017 07:20 AM, Denys Vlasenko wrote: > I'm not using their runtime debug thing (I don't even know what it is), > if some people would use it and find real bugs, it's good for me.
It's your call what to merge into busybox (and I see you already did), I was trying to figure out if I should make an analogous change to toybox (since I originally wrote this code and am using it there too). As far as I can tell the change is just churn: there's no even theoretical reproduction sequence for a bug because there's no bug. Just tea leaf reading about what future compilers might someday do, but which the past several decades of linux and other unixes consistently haven't had an issue with (and such a change would break more than just busybox). > Therefore, I'm willing to help them to not have false positives > which make their life harder. Well, unless they want some intrusive > and ugly changes. These changes were not. My attitude towards false positives may have been influenced by people running static checkers against toybox and submitting long spreadsheets of results, which I've spent hours going through and writing up my analysis of each hit, although I spent a lot more effort on it the first few times it happened: http://lists.landley.net/pipermail/toybox-landley.net/2014-February/003280.html My reluctance to "fix" non-bugs may have been informed by that sort of thing. SOMEBODY has to be able to reproduce the issue, or at least feasibly explain what they think might occur. When Daniel says "Where we find undefined behavior it should be fixed." I read "it" as the standard or the compiler at least as often as code that's consistently worked for many years on multiple architectures. C used to allow 6 bit char (ala PDP-10) and sizeof(char) could be 4 bytes (Cray did that) and those things went away later as hardware became more uniform over time. What the standards documented trailed the reality, and is still doing so. There are plenty things like endianness and alignment that still cause real world problems and you can point to a reproduction sequence "do this here and it does that" when that happens. But "undefined in this standard"? You've always needed multiple overlapping standards to describe a usable unix programming environment, and some of the standards are terrible (LSB), or abandoned (last I checked ELF is still hosted on the SCO website), or implicit (the Linux container spec is basically some man pages, lwn articles, and talks on youtube). I don't consider Posix not mentioning the "mount" command to be an argument for removing "mount" from unix. *shrug* I appear to be in the minority on this. Oh well. Rob P.S. Seriously, there's some really de-facto standards out there. The mips EABI documentation is a 15 year old mailing list post everybody links to http://www.cygwin.com/ml/binutils/2003-06/msg00436.html and here's the ARM fdpic documentation: https://github.com/mickael-guene/fdpic_manifest . And yet somehow we cope... _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
