Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 245 insertions, 0 deletions

diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn
new file mode 100644
index 00000000..45126b91
--- /dev/null
+++ b/open_issues/code_analysis/discussion.mdwn
@@ -0,0 +1,245 @@
+[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-12-04
+
+    <mcsim> defpager uses it's own dynamic memory allocator, which uses
+      vm_allocate/vm_deallocate as backing store? Am I able to use duma in such
+      case?
+    <braunr> you will have to adapt it
+    <braunr> but it's already designed to handle custom allocators
+    <braunr> iirc
+    <braunr> btw, are there special flags for that memory which the pager
+      allocates ?
+    <braunr> e.g. to use wired memory ?
+    <mcsim> yes, wired memory
+    <braunr> you'll have to change that in duma then
+    <braunr> but apart from such details, it should be straightforward
+
+    <antrik> braunr: I have no idea about duma; but if you think it's a useful
+      tool, please add it to open_issues/code_analysis.mdwn
+    <antrik> (I guess we should have a "proper" page listing useful debugging
+      tools...)
+
+
+## IRC, freenode, #hurd, 2012-09-03
+
+    <mcsim> hello. Has anyone tried some memory debugging tools like duma or
+      dmalloc with hurd?
+    <braunr> mcsim: yes, but i couldn't
+    <braunr> i tried duma, and it crashes, probably because of cthreads :)
+
+
+# Static Analysis
+
+## IRC, freenode, #hurd, 2012-09-08
+
+    <mcsim> hello. What static analyzer would you suggest (probably you have
+      tried it for hurd already)?
+    <braunr> mcsim: if you find some good free static analyzer, let me know :)
+    <pinotree> a simple one is cppcheck
+    <mcsim> braunr: I'm choosing now between splint and adlint
+
+
+## IRC, freenode, #hurd, 2013-10-17
+
+    <teythoon> whoa, llvm kinda works, enough to make scan-build work :)
+    <braunr> teythoon: what is scan-build ?
+    <teythoon> braunr: clangs static analyzer
+    <braunr> ok
+    <teythoon> I'm doing a full build of the hurd using it, I will post the
+      report once it is finished
+    <teythoon> this will help spot many problems
+    <teythoon> well, here are the scan-build reports I got so far:
+      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/
+    <teythoon> I noticed it finds problems in mig generated code, so there are
+      probably lot's of duplictaes for those kind of problems
+    <pinotree> what's a... better one to look at?
+    <teythoon> it's also good at spotting error handling errors, and can spot
+      leaks sometimes
+    <teythoon> hm
+    <teythoon>
+      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-yVBHO1.html
+    <braunr> that's minor, the device always exist
+    <braunr> but that's still ugly
+    <teythoon>
+      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-MtgWSa.html
+    <teythoon>
+      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-QdsZIm.html
+    <teythoon> this could be important:
+      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-PDMEbk.html
+    <teythoon> this is the issue it finds in mig generated server stubs:
+      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-iU3soc.html
+    <braunr> this one is #if TypeCheck1
+    <braunr> the libports one looks weird indeed
+    <teythoon> but TypeCheck is 1 (the tooltip shows macro expansion)
+    <teythoon> it is defined in line 23
+    <braunr> oh
+    <teythoon> hmmm... clang does not support nested functions, that will limit
+      its usefulness for us :/
+    <braunr> yes
+    <braunr> one more reason not to use them
+
+
+### IRC, freenode, #hurd, 2013-10-18
+
+    <teythoon> more complete, now with index:
+      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]].