[petsc-dev] http://www.c-faq.com/aryptr/non0based.html
Barry Smith
bsmith at mcs.anl.gov
Tue Mar 30 14:20:01 CDT 2010
On Mar 30, 2010, at 12:55 PM, William Gropp wrote:
> As long as you have a flat address space, this trick works. The
> problem is (was) for systems with memory segments; in that case,
> &realarray[-1] might not be valid.
Bill,
So is it then a question of using &something[invalidindex] that
is the only problem? We never do this in PETSc; we only do, for
example, a -= mstart; that is add or subtract to an already existing
valid address. Of course a[0] may now be invalid, but then the code is
written so those invalid indices are never used.
In other words replace
int *array = &realarray[-1];
with
int *array = &realarray[0];
array--; now use array[1]
Is the second form any more "valid" or "legal" then the first form? Or
are they equally "wrong".
Thanks
Barry
>
> Bill
>
> On Mar 30, 2010, at 12:30 PM, Barry Smith wrote:
>
>>
>> What do the PETSc developers think of this? Is it "otherwise,
>> the behavior is undefined, even if the pointer is not dereferenced."?
>>
>> Whenever we work with global indices like in
>> FormFunctionLocal() we do this.
>>
>> Is PETSc wrong to ever do this? Is there any other way to allow
>> users to work with global indices in a simple way? Do we need to
>> strip out all the FormFunctionLocals() from PETSc? Not the end of
>> the world but it provides such a nice simple interface for simple
>> problems it seems a pity to toss it.
>>
>> Thanks
>>
>> Barry
>>
>
> William Gropp
> Deputy Director for Research
> Institute for Advanced Computing Applications and Technologies
> Paul and Cynthia Saylor Professor of Computer Science
> University of Illinois Urbana-Champaign
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100330/ee73b86c/attachment.html>
More information about the petsc-dev
mailing list