summaryrefslogtreecommitdiff
path: root/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'microkernel/mach/gnumach/projects/clean_up_the_code.mdwn')
-rw-r--r--microkernel/mach/gnumach/projects/clean_up_the_code.mdwn111
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]]