[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: initialization of XXX_COOKIE in C source files
- To: petsc-dev@xxxxxxxxxxx
- Subject: Re: initialization of XXX_COOKIE in C source files
- From: "Matthew Knepley" <knepley@xxxxxxxxx>
- Date: Sun, 11 May 2008 07:07:56 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/QwUcfINdUvlOTVSGUr4eGIQ1GjGaqGHPM1CJ2rgLKk=; b=buhkWakaCk0g+UVePtv+YQL9TVY2ums31079+YHYnClqB2aIo+/2sGTsYyw69sRY7bL98Ks7ZXe7q6LUVvvIYCCWgFASAd7/1scosTusi0R3zHeXWGn44TpVlwLuQ1OmFqZ9fAUHvUUPh6gHcMxuPjbbxDxeZ3/GydS1wrqb62w=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RB1lnxVFvCc3JdeVkI8tY4wU7RkZFJpilOF07EjfMaeeRrc68gYjdU9XRasjctWjnxGLWD3XnVnH3IlFMfY4ppfGzGxEfJFsYQeTLTSOXikyAeLYl3vN+LIl3eJu7zwtGZUM6ghB2aeQ7MYEl4FCS4W+sSX5xt3EPc7HlqcgkV8=
- In-reply-to: <A51E66F9-0480-4CF3-B34A-06EA1EA19DD8@mcs.anl.gov>
- References: <e7ba66e40805101608nbeacf18l4f1cca4c00172e7e@mail.gmail.com> <A51E66F9-0480-4CF3-B34A-06EA1EA19DD8@mcs.anl.gov>
- Reply-to: petsc-dev@xxxxxxxxxxx
- Sender: owner-petsc-dev@xxxxxxxxxxx
On Sat, May 10, 2008 at 7:49 PM, Barry Smith <bsmith@xxxxxxxxxxx> wrote:
>
> On May 10, 2008, at 6:08 PM, Lisandro Dalcin wrote:
>
>
> > I've noticed that in 2.3.3 all PETSc cookies are initialized to zero
> > in sources, but in DEV they are not initialized. What's the reason of
> >
> ^^^^^^^^^^^^^^^^
> You are quick, I just pushed the change
> last night.
>
> The reason why they where all initialized to zero was because
> - a very long time ago all the cookies where hardwired numbers that we
> chose for each new class
> - then we added the ability to request a cookie, but still support the old
> hardwired version. Passing in a pointer to a zero value meant you were
> requesting one, passing in a pointer to a nonzero one meant that the
> cookie
> had a hardwired value.
> - over time all the hardwired ones were unhardwired, but the convention
> of initializing them to zero before hand was never changed.
>
> There was some convoluted logic for why the PetscEvent values were
> all initialized to zero also. When fixing up the events I also fixed the
> cookies
> The reason is Barry's rule # 54, "nothing should be done in a code without
> a reason, otherwise it will be confusing to others looking at the code."
> For example,
> even now, whenever anybody made some new events they initialized them
> to zero, why? Not because they need to be, but simply because they were in
> code the developer copied from.
>
> Were you taking advantage of their initialization to zero? If so, rather
> than depending
> on each cookie being initialized to zero I would suggest handling this type
> of "check if initialized" stuff at a package by package level or library by
> library level.
> Please let me know what you need.
Now I am a little worried. Don't some compilers dislike unintialized, file scope
variables in shared libraries (I am thinking AIX).
Matt
> Barry
>
>
>
>
> >
> > this change?
> >
> > --
> >
> > Lisandro Dalcín
> > ---------------
> > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> > PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> > Tel/Fax: +54-(0)342-451.1594
> >
> >
>
>
--
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener