Multiple Array and pointer issue

[Ron Blancarte]

I was looking through the newsgroup FAQ for an answer to my question,
but it doesn't appear to have one.

I am working with a system that has VERY limited memory. I was
defining two buffers to pass in and out data:

unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

But now it turns out I need the output buffer to be larger under
certain cases. What I wanted to do was make the output buffer double
size:

unsigned char outputBuffer[200];

And then use the input buffer as a portion of outputBuffer:

unsigned char *inputBuffer = outputBuffer + 100;

When necessary, the outputBuffer could then use the large array and
inputBuffer would have it's space as well, without having to allocate
the extra 100 bytes for the outputBuffer.
So I made this change, however, now input is not working. I would
have thought subscripting that was existing in code would still work.
My code all uses inputBuffer[location] as means of accessing the
inputBuffer.

So my question is, what am I doing wrong?

RonB

[Old Wolf]

On Jun 8, 9:39 am, Ron Blancarte wrote:

*((char*)&spiSi ze ) = inputBuffer[1];
*((char*)&spiSi ze+1) = inputBuffer[2];

This code is suspicious; you would be much
better off writing:
spiSize = inputBuffer[1] * 0x100 + inputBuffer[2];

or perhaps the other way around depending on
the desired result.

However, that probably isn't the source of your
problem. Based on the information provided,
I'd have to suspect you're overflowing the
output and thus overwriting your input, or you
are using 'sizeof' on the pointer. You could
debug the former by writing a sentinel value to
outputBuffer[99] and checking if it is still
there when you apparently have the garbage in
inputBuffer.

[Karl Malbrain]

"CBFalconer " <cb********@yah oo.comwrote in message
news:46******** *******@yahoo.c om...

Ron Blancarte wrote:

>>

... snip ...

>>
ONE THING!!
I don't know if this makes a difference or not, BUT...
I forgot to mention, inputBuffer and outputBuffer are both global.
They are being accessed via extern in the SPI routines. Will this
make any sort of differnce?

Please snip immaterial quoted material.

The answer is quite likely yes. They will affect anything such as
"sizeof buffer".

AND....
the SPI routines are going to expect character arrays, not character
pointers.

karl m

[Keith Thompson]

"Karl Malbrain" <ma******@yahoo .comwrites:

"CBFalconer " <cb********@yah oo.comwrote in message
news:46******** *******@yahoo.c om...

>Ron Blancarte wrote:

>>>

... snip ...

>>>
ONE THING!!
I don't know if this makes a difference or not, BUT...
I forgot to mention, inputBuffer and outputBuffer are both global.
They are being accessed via extern in the SPI routines. Will this
make any sort of differnce?

Please snip immaterial quoted material.

The answer is quite likely yes. They will affect anything such as
"sizeof buffer".

AND....
the SPI routines are going to expect character arrays, not character
pointers.

I don't know what "SPI routines" are, but if they're declared in C,
that hardly seems likely.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Torek]

>On Thu, 07 Jun 2007 13:39:39 -0500 (while OU was sucking), Ron

>Blancarte wrote:

>>unsigned char inputBuffer[100];
unsigned char outputBuffer[100];

[then outputBuffer[] size increased and the other replaced, viz:
unsigned char outputBuffer[200];
unsigned char *inputBuffer = outputBuffer + 100;
]

In article <0v************ *************** *****@4ax.com>
Ron Blancarte <[e-mail] rote:

>ONE THING!!
I don't know if this makes a difference or not, BUT...
I forgot to mention, inputBuffer and outputBuffer are both global.
They are being accessed via extern in the SPI routines. Will this
make any sort of differnce?

I am going to make a wild guess at the problem: you changed
the actual definitions of the two variables, but somewhere else
-- where they are used, as these "global" variables -- you left
in *declarations* of the form:

extern char inputBuffer[];
extern char outputBuffer[];

Since arrays are not pointers (nor vice versa), this causes
references of the form:

inputBuffer[i]

to generate "array access" instructions instead of the "pointer
accesss" instructions now need. (See the FAQ, section 6.)

Note that you may be able to get "better" (for some definition
of "better") code by writing:

unsigned char outputBuffer[200];
#define inputBuffer (&outputBuffe r[100])

and/or using (off-topic, but probably-available) assembler or
linker tricks to make the two buffers overlap. That is, on some
microprocessors , if some variable A is an array while some other
variable p is a pointer pointing into that array -- e.g.:

char A[100];
char *p = &A[0];

-- then, on that machine, the code generated for:

op(A[i])

is shorter and/or faster than that for:

op(p[i])

for most operations "op". (On other machines, it is a wash, and
in some cases, the pointer may be "better". The definition of
"better" is rather fuzzy in the first place, so this is something
that has to be defined clearly, then measured.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Ron Blancarte]

On 8 Jun 2007 00:17:10 GMT, Chris Torek wrote:

>I am going to make a wild guess at the problem: you changed
the actual definitions of the two variables, but somewhere else
-- where they are used, as these "global" variables -- you left
in *declarations* of the form:

extern char inputBuffer[];
extern char outputBuffer[];

I was thinking the same thing, but no, not the problem. However, you
did mention...

>Note that you may be able to get "better" (for some definition
of "better") code by writing:

unsigned char outputBuffer[200];
#define inputBuffer (&outputBuffe r[100])

>and/or using (off-topic, but probably-available) assembler or
linker tricks to make the two buffers overlap. That is, on some
microprocessor s, if some variable A is an array while some other
variable p is a pointer pointing into that array -- e.g.:

Which got me digging into assembly, etc. It turns out that since I
was declaring the inputBuffer globally:

unsigned char outputBuffer[200];
unsigned char *inputBuffer = outputBuffer + 100;

the value was being set at startup. The assembly code which was
running was re-mapping the XDATA space of the chip after this line.
It erased the pointer.

RonB