Merge remote-tracking branch 'feldtkeller.SCHWINGE/master'

Conflicts:
	news/2011-q2.mdwn
	open_issues/glibc.mdwn
	open_issues/versioning.mdwn

1 files changed, 107 insertions, 4 deletions

diff --git a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn
index 89a27b01..0ca6d91e 100644
--- a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn
+++ b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn
@@ -1,13 +1,13 @@
-[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2010, 2012 Free Software
-Foundation, Inc."]]
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2010, 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 [[!tag open_issue_gnumach]]
 
@@ -130,3 +130,106 @@ further files (also exported ones) that serve no real value, but are being
     <mcsim> this parameter has name data_count
     <braunr> that's one of the reasons mach is confusing
     <braunr> i can't really tell you why, it's messy :/
+
+
+# [[open_issues/Code_Analysis]], *Coverity*
+
+## IRC, freenode, #hurd, 2014-02-03
+
+    <teythoon> braunr: at the end of kmem_cache_error the comment says 'never
+      reached'. i do not believe that to be true...
+    <braunr> teythoon: yes, this is a mistake
+    <braunr> those kmem_error calls were panics in the original version
+    <braunr> the comment was left over
+    <braunr> or rather, the panic equivalent not added
+
+
+### IRC, freenode, #hurd, 2014-02-04
+
+    <teythoon> braunr: but the code relies uppon the fact that kmem_cache_error
+      does not return
+    <teythoon> the fact that it doesn't upsets static analysis tools
+    <teythoon>
+      http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2014-01-17/report-DfjC43.html#Path9
+    <braunr> 21:20 < braunr> or rather, the panic equivalent not added
+    <braunr> teythoon: you're right
+    <braunr> it needs to be fixed
+    <teythoon> i setup a coverity project for gnu mach
+    <teythoon> it's interesting
+    <teythoon> very enterprisy >,<
+    <braunr> teythoon: heh
+    <teythoon> braunr: i assume kmem_error is supposed to panic
+    <teythoon> if so, i'd propose to use panic instead of printf in that macro
+      definition
+    <braunr> yes
+    <braunr> teythoon: again, that's how it's done in the original
+      implementation
+    <teythoon> and fix kmem_cache_error to use kmem_warn near the top of the
+      function
+    <braunr> teythoon: i suggest you use the x15 variant as a reference
+      (http://git.sceen.net/rbraun/x15.git/blob/HEAD:/kern/kmem.c)
+    <teythoon> right
+
+
+### IRC, OFTC, #debian-hurd, 2014-02-05
+
+    <pere> ah, cool.  <URL: https://scan.coverity.com/projects/1307 >
+      is now in place. :)
+    <teythoon> pere: it was you who made me create the coverity project
+    <teythoon> and it was most fruitful already
+    <pere> glad to hear that. :)
+    <pere> while the mach thread made me discover scan-build, which
+      seem promising but have way to few rules.
+    <pere> teythoon: btw, could I get access to the mach coverity
+      status?
+    <teythoon> pere: sure
+    <pere> I've used up all my 'join project' slots, so I suspect you
+      have to invite me.  try pere@hungry.com
+    <teythoon> pere: ok
+    <teythoon> pere: i'm fuzzy about the roles
+    <teythoon> what kind of invite shall i send you ?
+    <pere> not sure either.
+    <teythoon> ok
+    <pere> contributor/* would be fine for me.  want to check the
+      details, not just the overview.
+    <teythoon> oh
+    * pere looked up the role description
+    <teythoon> do you have a link ?
+    <teythoon> i can always change the role afaics
+    <pere> go to the member list, found it there.
+    <pere> (the link is project specific, it seem.
+    <teythoon> right, found it
+    <pere> gah, it gave me a new user. :(
+    <pere> I assumed I would be allowed to accept the invite using my
+      normal user.
+    <pere> can you try again with pere-github@hungry.com, which
+      hopefully will hook the invite to my github authenticated user?
+    <teythoon> sure
+    <pere> were you allowed to invite that address?
+    <pere> ah, I got it in my dashboard without having to do anything
+      more.
+    <pere> heh, the email I got claimed the user would not be created
+      unless I provided a password, but given the member list for mach,
+      I fail to see how that could be true.
+
+
+### IRC, OFTC, #debian-hurd, 2014-02-06
+
+    <teythoon> pere: your coverity invitations are still saying 'not
+      accepted', did neither work ?
+    <pere> teythoon: one worked just fine.  I got access.  the other I
+      did not accept.
+    <teythoon> pere: good :)
+
+
+### IRC, OFTC, #debian-hurd, 2014-02-25
+
+    <pere> I am quite impressed with the defect density of Mach, <URL:
+      https://scan.coverity.com/projects/1307 >. :)
+    <pere> 12 outstanding issues (but 54 dismissed was surprisingly
+      high :).
+    <youpi> pere: 54 dismissed because that's a pattern generated by
+      mig
+    <youpi> repeated dozens of times
+
+[[!tag open_issue_mig]]