From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- open_issues/code_analysis/discussion.mdwn | 142 +++++++++++++++++++++++++++++- 1 file changed, 141 insertions(+), 1 deletion(-) (limited to 'open_issues/code_analysis') diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn index 4cb03293..45126b91 100644 --- a/open_issues/code_analysis/discussion.mdwn +++ b/open_issues/code_analysis/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -100,6 +100,146 @@ License|/fdl]]."]]"""]] https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build-2/ +### IRC, freenode, #hurd, 2013-11-04 + + btw, why does the nested functions stuff needs the executable + stack? for trampolines? + yes + I didn't even realize that, that's one more reason to avoid them + indeed + + braunr: kern/slab.c (1471): vm_size_t info_size = info_size; + yes ? + braunr: what's up with that? + that's one way to silence gcc warnings about uninitialized + variables + this warning can easily result in false positives when gcc is + unable to determine dependencies + e.g. if (flag & FLAG_CREATE) myvar = create(); ...; ... if (flag & + FLAG_CREATE) use(myvar) + well, ok, that's a shortcomming of gcc + braunr: your way of silencing that in gcc still shows up in + scan-build and most likely any more advanced analysis tool + as it should of course, but it is noisy + teythoon: there is a gcc attribute for that + __attribute__((unused)) + analysis tools might know that better + braunr: could you have a quick look at + http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-mXqstT.html#EndPath + ? + nice + anything else on the rbtree code ? + well + + http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-LyiOO1.html#EndPath + but this is of length 18, so it might be far-fetched + ?? + the length of the chain of argumentation + i don't understand that issue + isn't 18 the analysis step ? + well, the greater the length, the more assumption the tool + makes, the more likely it is that it just does not "get" some invariant + probably yes + the code can segfault if input parameters are invalid + that's expected + right, looks like this only happens if the tree is invalid + if in line 349 brother->children[right] is NULL + this is a very good target for verification using frama-c + :) + the code already has many assertions that will be picked up by + it automatically + so what about the dead store, is it a bug or is it harmless ? + harmless probably + certainly + a simple overlook when polishing + + +### IRC, freenode, #hurd, 2014-01-16 + + braunr: hi. Once, when I wrote a lot if inline gcc functions in + kernel you said me not to use them. And one of the arguments was that you + want to know which binary will be produced. Do you remember that? + not exactly + it seems likely that i advice not to use many inline functions + but i don't see myself stating such a reason + braunr: ok + so, what do you think about using some high level primitives in + kernel + like inline-functions + ? + "high level primitives" ? + you mean switching big and important functions into inline code ? + braunr: something that is hard to translate in assembly directly + braunr: I mean in general + i think it's bad habit + braunr: why? + don't inline anything at first, then profile, then inline if + function calls really are a bottleneck + my argument would be that it makes code more readable + https://www.kernel.org/doc/Documentation/CodingStyle <= see the + "inline disease" + uh + more readable ? + the only difference is an inline keyword + sorry + i confused with functions that you declare inside functions + nested + forgot the word + sorry + ah nested + my main argument against nested functions is that they're not + standard and hard to support for non-gcc tools + another argument was that it required an executable stack but + there is apparently a way to reliably make nested functions without this + requirement + so, at the language level, they bring nice closures + the problem for me is at the machine level + i don't know them well so i'm unable to predict the kind of code + they generate + but i guess anyone who would take the time to study their + internals would be able to do that + and why this last argument is important? + because machine code runs on machines + one shouldn't ignore the end result .. + if you don't know the implications of what you're doing precisely, + you loose control over the result + if you can trust the tool, fine + mcsim: in general, when you use something you don't really + understand how it works internally, you've a much higher risk of making + bugs or inefficient code because you just didn't realize it couldn't work + or would be inefficient + but in the case of a kernel, it often happens that you can't, or + at least not in a straightforward way + s/loose/lose/ + kilobug: and that's why for kernel programming you try to use the + most straightforward primitives as possible? + no + mcsim: not necessarily the most straightforward ones, but ones + you understand well + keeping things simple is a way to keep control complexity in any + software + as long as you understand, and decouple complicated things apart, + you can keep things simple + nested functions doesn't have to do with complexity + don't* + it's just that, since they're not standard and commonly used + outside gnu projects, they're not well known + i don't "master" them + also, they decouple the data flow from the control flow + which in my book is bad for imparative languages + and support for them in tools like gdb is poor + braunr: I remembered nested functions because now I use C++ and I + question myself if I may use all these C++ facilities, like lambdas, + complicated templates and other stuff. + kilobug: And using only things that you understand well sounds + straightforward and logical + that's why i don't write c++ code :) + it's very complicated and requires a lot of effort for the + developer to actually master it + mcsim: you can use those features, but sparsely, when they really + do bring something useful + + # Leak Detection See *Leak Detection* on [[boehm_gc]]. -- cgit v1.2.3