<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 4:06 PM, Karl Rupp <span dir="ltr"><<a href="mailto:rupp@mcs.anl.gov" target="_blank">rupp@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>* We have a couple of malloc/free in use:<br>
<a href="http://krupp.iue.tuwien.ac.at/petsc-style/malloc-free.txt" target="_blank">http://krupp.iue.tuwien.ac.at/<u></u>petsc-style/malloc-free.txt</a><br>
Except for the actual implementation of PetscMalloc() and the like somewhere in src/sys/, is there anything I have to keep in mind when fixing the other uses?<br></div></blockquote><div><br></div><div style>The cases in mesh.c and plex.c are freeing memory allocated by an external library.</div>
<div style><br></div><div style>options.c can be processed before the correct malloc implementation has been determined (because it can be a command-line option).</div><div style><br></div><div style>str.c stuff can be called before PetscInitialize</div>
<div style><br></div><div style>hash.h is a third-party library that was brought in and was not fully petsc-fied.</div><div style><br></div><div style>yamlimpls.c is freeing memory allocated by an external library</div><div style>
<br></div><div style>The tfs stuff was contributed and never petsc-fied. I don't think it's worth doing maintenance on because it will have to be substantially rewritten if someone wants to extend it in a nontrivial way.</div>
<div style><br></div><div style>That pretty much covers it, so I think PETSc is okay on this front.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>

<br>
* CHKERRQ is missing at a couple of places:<br>
<a href="http://krupp.iue.tuwien.ac.at/petsc-style/ierr-chkerr.txt" target="_blank">http://krupp.iue.tuwien.ac.at/<u></u>petsc-style/ierr-chkerr.txt</a><br>
I noticed that PetscPrintf() is hardly ever checked for the value of ierr. Is this intentional? If yes, which other functions in PETSc should not be checked for the return value in ierr = ...?<br></div></blockquote><div>

<br></div><div>It looks like most of these are accidentally missing. CHKERRABORT can be used when the function does not return PetscErrorCode, but the function should really be fixed to return PetscErrorCode.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
* There is quite some dead code around:<br>
<a href="http://krupp.iue.tuwien.ac.at/petsc-style/if0.txt" target="_blank">http://krupp.iue.tuwien.ac.at/<u></u>petsc-style/if0.txt</a><br>
Are there any objections (or even LOUD objections) in removing all blocks which are older than ~1 year?<br></div></blockquote><div><br></div><div style>This may need to be done on a case by case basis, but most of it can probably go. I wouldn't put any effort into src/dm/impls/{mesh,cartesian} because I suspect that code will be deleted en masse within a year.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
* src/contrib/markadamscolor/<u></u>color.c is the only place using assert():<br>
<a href="http://krupp.iue.tuwien.ac.at/petsc-style/assert.txt" target="_blank">http://krupp.iue.tuwien.ac.at/<u></u>petsc-style/assert.txt</a><br>
Since color.c entered in the previous century and hasn't been notably touched since at least 2001, is there any reason other than software archeology for keeping it?<br></div></blockquote></div><br>I don't know what other people think about the contrib directory. It has a lot of cobwebs in it, but it can be fun to look at sometimes. The FUN3D code in there is now out of date with respect to PETSc and METIS interfaces. Somewhere along the line, comp/flow.c became syntactically incorrect. (Perhaps reformatting interacted poorly its heavy use of macros.)</div>
</div>