one before the end of array

[gc]

I noticed that when f2c converts a fortran subroutine to a c function
it decrements the pointer sent as an argument to the function and then
uses 1 based addressing system. If am I not wrong, one can increment
a pointer to one past the end of the array but not reference it. But
does a similar rule hold for one before the beggining of an array?
I am currently using an array larger than the required size by one and
sending array+1 as to the function just to be safe i.e., instead of

double a[]={1.,2.,3.};
f(a);

I am doing
double a[]={/*some junk*/-1.,1.,2.,3.};
f(a+1);

but is it really necessary?

[Richard Heathfield]

gc wrote:

I noticed that when f2c converts a fortran subroutine to a c function
it decrements the pointer sent as an argument to the function and then
uses 1 based addressing system.
Naughty f2c.
If am I not wrong, one can increment
a pointer to one past the end of the array but not reference it.
Right.
But
does a similar rule hold for one before the beggining of an array?
No. The behaviour is undefined.
I am currently using an array larger than the required size by one and
sending array+1 as to the function just to be safe i.e.,
A very sensible precaution.
instead of

double a[]={1.,2.,3.};
f(a);

I am doing
double a[]={/*some junk*/-1.,1.,2.,3.};
f(a+1);

but is it really necessary?

It makes the behaviour of your program well-defined. Is that really
necessary? I think so, yes.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Daniel Vallstrom]

gu**********@yahoo.com (gc) wrote in message news:<79**************************@posting.google. com>...

I noticed that when f2c converts a fortran subroutine to a c function
it decrements the pointer sent as an argument to the function and then
uses 1 based addressing system. If am I not wrong, one can increment
a pointer to one past the end of the array but not reference it.
Correct. The reason it's allowed is that it's useful and easy to
implement for compiler writers. You only need to make sure that adding
1 to the pointer makes sense which it does if e.g. there is a single
extra byte after the last element in the array.
But
does a similar rule hold for one before the beggining of an array?
No, it's UB. The reason is that, although IMO it would be useful just
like the after-pointer, it could be difficult to support: Let T be a
very large type of size 1GB say. Let p be a T pointer: T * p; Then
p-1 would point 1G bytes before p which could be troublesome. This in
contrast to p+1 which just points to one byte after the last byte of
*p.

Note though that for small types there would be no problem allowing
p-1, just like p+1 is allowed. I actually suggested this here

http://groups.google.com/groups?hl=e...Dcomp.lang.c.*

but basically no one else thought it was a good idea. The common
opinion was that before pointers aren't as useful as after pointers
and that just what would be allowed, i.e. what would constitute a
small type, would be messy.
I am currently using an array larger than the required size by one and
sending array+1 as to the function just to be safe i.e., instead of

double a[]={1.,2.,3.};
f(a);

I am doing
double a[]={/*some junk*/-1.,1.,2.,3.};
f(a+1);

but is it really necessary?

If you don't want UB it's necessary. For reasons discussed above
it's likely that your program would work fine also without the fix.
However, in your case it's an easy fix so why not do it? If the fix
would be hard or wasteful you should take into account the likelihood
of introducing bugs with the fix, memory waste etc. and weight that
against the likelihood of running the program somewhere where the
before pointer would break things.
Daniel Vallstrom