Okay. By "typo" I meant that I never intended to have a "const PetscInt" argument. It just got contaminated from the nearby "const PetscInt *". I'm not sure what meaning "const PetscInt" would have, since C has pass-by-value semantics, but I'm not sure whether some C-subtlety might be at play here.
On Wed, Aug 17, 2011 at 10:34 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On Aug 17, 2011, at 1:31 PM, Dmitry Karpeev wrote: > >> That's just a typo on my part. >> I'm rewriting the whole SA ball of wax, but I can push a quicker fix >> for this too, > > ? What do you mean typo? I fixed the repository so that the declaration and > the prototype match. You don't need to do anything. > > ? But my question remains, should we const declare function arguments? > > ?barry > >> but, unfortunately, I won't be able to do that untill next Monday. >> >> >> Dmitry. >> >> On Wed, Aug 17, 2011 at 10:09 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: >>> >>> ? Some declarations of the form >>> >>> extern PetscErrorCode SAAddData(SA arr, const PetscInt len, const PetscInt >>> *ia, const PetscScalar *wa, const PetscInt *ja); >>> >>> have crept into PETSc. ?const PetscInt len >>> >>> Do we want to have such beasties? What purpose do they serve? >>> >>> My understanding is that it is contaminating the entire code (because of >>> the extern PetscErrorCode SAAddData(SA arr, const PetscInt len, const >>> PetscInt *ia, const PetscScalar *wa, const PetscInt *ja); with the >>> knowledge that internally the subroutine never changes the value of the >>> stack variable function which is the opposite of encapsulation. What am I >>> missing? Is this just stupid C syntax, is there a better way? >>> >>> ? Thanks >>> >>> ? ?Barry >>> >>> > >
