[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.


     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];
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".



> 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