summaryrefslogtreecommitdiff
path: root/open_issues/code_analysis
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2014-02-26 12:32:06 +0100
committerThomas Schwinge <thomas@codesourcery.com>2014-02-26 12:32:06 +0100
commitc4ad3f73033c7e0511c3e7df961e1232cc503478 (patch)
tree16ddfd3348bfeec014a4d8bb8c1701023c63678f /open_issues/code_analysis
parentd9079faac8940c4654912b0e085e1583358631fe (diff)
IRC.
Diffstat (limited to 'open_issues/code_analysis')
-rw-r--r--open_issues/code_analysis/discussion.mdwn142
1 files changed, 141 insertions, 1 deletions
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
+
+ <teythoon> btw, why does the nested functions stuff needs the executable
+ stack? for trampolines?
+ <braunr> yes
+ <teythoon> I didn't even realize that, that's one more reason to avoid them
+ indeed
+
+ <teythoon> braunr: kern/slab.c (1471): vm_size_t info_size = info_size;
+ <braunr> yes ?
+ <teythoon> braunr: what's up with that?
+ <braunr> that's one way to silence gcc warnings about uninitialized
+ variables
+ <braunr> this warning can easily result in false positives when gcc is
+ unable to determine dependencies
+ <braunr> e.g. if (flag & FLAG_CREATE) myvar = create(); ...; ... if (flag &
+ FLAG_CREATE) use(myvar)
+ <teythoon> well, ok, that's a shortcomming of gcc
+ <teythoon> braunr: your way of silencing that in gcc still shows up in
+ scan-build and most likely any more advanced analysis tool
+ <teythoon> as it should of course, but it is noisy
+ <braunr> teythoon: there is a gcc attribute for that
+ <braunr> __attribute__((unused))
+ <braunr> analysis tools might know that better
+ <teythoon> braunr: could you have a quick look at
+ http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-mXqstT.html#EndPath
+ ?
+ <braunr> nice
+ <braunr> anything else on the rbtree code ?
+ <teythoon> well
+ <teythoon>
+ http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-LyiOO1.html#EndPath
+ <teythoon> but this is of length 18, so it might be far-fetched
+ <braunr> ??
+ <teythoon> the length of the chain of argumentation
+ <braunr> i don't understand that issue
+ <braunr> isn't 18 the analysis step ?
+ <teythoon> well, the greater the length, the more assumption the tool
+ makes, the more likely it is that it just does not "get" some invariant
+ <braunr> probably yes
+ <braunr> the code can segfault if input parameters are invalid
+ <braunr> that's expected
+ <teythoon> right, looks like this only happens if the tree is invalid
+ <teythoon> if in line 349 brother->children[right] is NULL
+ <teythoon> this is a very good target for verification using frama-c
+ <braunr> :)
+ <teythoon> the code already has many assertions that will be picked up by
+ it automatically
+ <teythoon> so what about the dead store, is it a bug or is it harmless ?
+ <braunr> harmless probably
+ <braunr> certainly
+ <braunr> a simple overlook when polishing
+
+
+### IRC, freenode, #hurd, 2014-01-16
+
+ <mcsim> 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?
+ <braunr> not exactly
+ <braunr> it seems likely that i advice not to use many inline functions
+ <braunr> but i don't see myself stating such a reason
+ <mcsim> braunr: ok
+ <mcsim> so, what do you think about using some high level primitives in
+ kernel
+ <mcsim> like inline-functions
+ <mcsim> ?
+ <braunr> "high level primitives" ?
+ <braunr> you mean switching big and important functions into inline code ?
+ <mcsim> braunr: something that is hard to translate in assembly directly
+ <mcsim> braunr: I mean in general
+ <braunr> i think it's bad habit
+ <mcsim> braunr: why?
+ <braunr> don't inline anything at first, then profile, then inline if
+ function calls really are a bottleneck
+ <mcsim> my argument would be that it makes code more readable
+ <braunr> https://www.kernel.org/doc/Documentation/CodingStyle <= see the
+ "inline disease"
+ <braunr> uh
+ <braunr> more readable ?
+ <braunr> the only difference is an inline keyword
+ <mcsim> sorry
+ <mcsim> i confused with functions that you declare inside functions
+ <mcsim> nested
+ <mcsim> forgot the word
+ <mcsim> sorry
+ <braunr> ah nested
+ <braunr> my main argument against nested functions is that they're not
+ standard and hard to support for non-gcc tools
+ <braunr> another argument was that it required an executable stack but
+ there is apparently a way to reliably make nested functions without this
+ requirement
+ <braunr> so, at the language level, they bring nice closures
+ <braunr> the problem for me is at the machine level
+ <braunr> i don't know them well so i'm unable to predict the kind of code
+ they generate
+ <braunr> but i guess anyone who would take the time to study their
+ internals would be able to do that
+ <mcsim> and why this last argument is important?
+ <braunr> because machine code runs on machines
+ <braunr> one shouldn't ignore the end result ..
+ <braunr> if you don't know the implications of what you're doing precisely,
+ you loose control over the result
+ <braunr> if you can trust the tool, fine
+ <kilobug> 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
+ <braunr> but in the case of a kernel, it often happens that you can't, or
+ at least not in a straightforward way
+ <braunr> s/loose/lose/
+ <mcsim> kilobug: and that's why for kernel programming you try to use the
+ most straightforward primitives as possible?
+ <braunr> no
+ <kilobug> mcsim: not necessarily the most straightforward ones, but ones
+ you understand well
+ <braunr> keeping things simple is a way to keep control complexity in any
+ software
+ <braunr> as long as you understand, and decouple complicated things apart,
+ you can keep things simple
+ <braunr> nested functions doesn't have to do with complexity
+ <braunr> don't*
+ <braunr> it's just that, since they're not standard and commonly used
+ outside gnu projects, they're not well known
+ <braunr> i don't "master" them
+ <teythoon> also, they decouple the data flow from the control flow
+ <teythoon> which in my book is bad for imparative languages
+ <teythoon> and support for them in tools like gdb is poor
+ <mcsim> 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.
+ <mcsim> kilobug: And using only things that you understand well sounds
+ straightforward and logical
+ <braunr> that's why i don't write c++ code :)
+ <braunr> it's very complicated and requires a lot of effort for the
+ developer to actually master it
+ <braunr> mcsim: you can use those features, but sparsely, when they really
+ do bring something useful
+
+
# Leak Detection
See *Leak Detection* on [[boehm_gc]].