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

[Eric Sosman]

Ron Blancarte wrote On 06/07/07 13:08,:

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?

There's nothing inherently wrong with your pointer
arithmetic, if that's what's worrying you. Note, though,
that this doesn't magically create 100 extra bytes out
of thin air. What you're actually doing is sharing the
latter half of the 200-char buffer, using those locations
for input and for the tail end of long outputs. Are your
output characters stomping all over your inputs before
you've processed them? Are you, say, reading data into
inputBuffer, then filling outputBuffer with blanks, then
trying to process the suddenly all-blank inputBuffer?

Without having seen any code, that's about all the
guessing I can manage.

--
Er*********@sun.com

[Ron Blancarte]

On Thu, 07 Jun 2007 13:25:19 -0400 (while OU was sucking), Eric Sosman
wrote:

>Ron Blancarte wrote On 06/07/07 13:08,:

>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?

There's nothing inherently wrong with your pointer
arithmetic, if that's what's worrying you. Note, though,
that this doesn't magically create 100 extra bytes out
of thin air. What you're actually doing is sharing the
latter half of the 200-char buffer, using those locations
for input and for the tail end of long outputs. Are your
output characters stomping all over your inputs before
you've processed them? Are you, say, reading data into
inputBuffer, then filling outputBuffer with blanks, then
trying to process the suddenly all-blank inputBuffer?

Without having seen any code, that's about all the
guessing I can manage.

Damn, I did leave out a paragraph on this.

So yea, I didn't magically create 100 bytes, I am just sharing that
back 100 under the special circumstances (which I won't mind if I
clobber the information in the input Buffer). Normal cases should not
be a problem

What problem that I am having is that it seems my functions which
worked with:

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

don't appear to be working with:

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

These are functions which don't produce enough data to actually hit
the 100 byte limit.

For example:

void SPI_receive()
{
systat_7 = 0;
SPICON = 0x31;
SPI_COMM_SS = 0;
SPIDAT = 0;
while (ISPI == 0);
inputBuffer[spi_in] = SPIDAT;
++spi_in;
if(!(--spiSize)){
systat_3 = 1;
systat_1 = 0;
}
SPI_COMM_SS = 1;
}

void spi_getSize()
{
*((char*)&spiSize ) = inputBuffer[1];
*((char*)&spiSize+1) = inputBuffer[2];
}

void SPI_send()
{
systat_7 = 0;
SPICON = 0x31;
if(!systat_5){
SPI_COMM_SS = 0;
SPIDAT = outputBuffer[OB_out];
while (ISPI == 0);
if(!(--spiSize))
systat_5 = 1;
++OB_out;
ISPI = 0;
SPI_COMM_SS = 1;
}
else{
systat_1 = systat_3 = systat_5 = systat_6 = 0;
systat_4 = 1;
}
}

These appear to be my problem functions right now. What happens is
that you xfer 3 bytes of data over the SPI bus initially. Then you
call spi_getSize(), so you know how many characters are being sent.
Then you start to use SPI_receive() to pull data off the bus 1
character at a time and place it into the buffer. After some
processing is done, and then the response is sent back out across the
SPI bus via SPI_send.

spi_in and OB_out are just indices which allow me to traverse
character by character through the buffers. There is an out and in
indice for each buffer (spi_in/spi_out and OB_in/OB_out)

RonB

[Ron Blancarte]

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

>On Thu, 07 Jun 2007 13:25:19 -0400 (while OU was sucking), Eric Sosman
wrote:

>>Ron Blancarte wrote On 06/07/07 13:08,:

>>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?

There's nothing inherently wrong with your pointer
arithmetic, if that's what's worrying you. Note, though,
that this doesn't magically create 100 extra bytes out
of thin air. What you're actually doing is sharing the
latter half of the 200-char buffer, using those locations
for input and for the tail end of long outputs. Are your
output characters stomping all over your inputs before
you've processed them? Are you, say, reading data into
inputBuffer, then filling outputBuffer with blanks, then
trying to process the suddenly all-blank inputBuffer?

Without having seen any code, that's about all the
guessing I can manage.

Damn, I did leave out a paragraph on this.

So yea, I didn't magically create 100 bytes, I am just sharing that
back 100 under the special circumstances (which I won't mind if I
clobber the information in the input Buffer). Normal cases should not
be a problem

What problem that I am having is that it seems my functions which
worked with:

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

don't appear to be working with:

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?

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

These are functions which don't produce enough data to actually hit
the 100 byte limit.

For example:

void SPI_receive()
{
systat_7 = 0;
SPICON = 0x31;
SPI_COMM_SS = 0;
SPIDAT = 0;
while (ISPI == 0);
inputBuffer[spi_in] = SPIDAT;
++spi_in;
if(!(--spiSize)){
systat_3 = 1;
systat_1 = 0;
}
SPI_COMM_SS = 1;
}

void spi_getSize()
{
*((char*)&spiSize ) = inputBuffer[1];
*((char*)&spiSize+1) = inputBuffer[2];
}

void SPI_send()
{
systat_7 = 0;
SPICON = 0x31;
if(!systat_5){
SPI_COMM_SS = 0;
SPIDAT = outputBuffer[OB_out];
while (ISPI == 0);
if(!(--spiSize))
systat_5 = 1;
++OB_out;
ISPI = 0;
SPI_COMM_SS = 1;
}
else{
systat_1 = systat_3 = systat_5 = systat_6 = 0;
systat_4 = 1;
}
}

These appear to be my problem functions right now. What happens is
that you xfer 3 bytes of data over the SPI bus initially. Then you
call spi_getSize(), so you know how many characters are being sent.
Then you start to use SPI_receive() to pull data off the bus 1
character at a time and place it into the buffer. After some
processing is done, and then the response is sent back out across the
SPI bus via SPI_send.

spi_in and OB_out are just indices which allow me to traverse
character by character through the buffers. There is an out and in
indice for each buffer (spi_in/spi_out and OB_in/OB_out)

RonB

[Eric Sosman]

Ron Blancarte wrote On 06/07/07 14:39,:

[...]
What problem that I am having is that it seems my functions which
worked with:

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

don't appear to be working with:

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

Of course this won't "work:" It won't even compile.
And if the first `inputBuffer' is really `outputBuffer',
then the buffer isn't big enough. We can sit here all
day trying to guess how to change what you've shown to
get to what your code is actually like, but in the end
that just means we're debugging our guesses and not
debugging your code.

If you feel ill, do you send your doctor a crayon
drawing of your body with an arrow saying "This is where
it hurts?"

If your car won't start, do you call the garage and
tell the mechanic "It's a sort of off-blue color, more
toward aqua. What's wrong with it?"

I'm not asking for you to post all umpty-bazillion
lines of your code (and I wouldn't read it if you did).
Whittle the code down to the smallest complete and
compilable program that demonstrates the problem, and
post that exact code: No paraphrases, no abbreviations,
no fill-in-the-blanks, but something another person can
run through his compiler unmodified. That way, we'll
be debugging your code instead of debugging a sort of
cloud of more and less likely possibilities centered
around your code.

Oh, and one more thing: "input is not working" is
not a sufficiently precise description of your problem.
In what way is it "not working?" What actually happens,
and how does that differ from what you hoped would happen?
Some people on this group seem to be able to read minds
on occasion, but it's not a reliable talent.

People *will* try to help you, but you've got to
cooperate more actively.

--
Er*********@sun.com

[Karl Malbrain]

"Ron Blancarte" <[e-mail] in message
news:0v********************************@4ax.com...

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

>>On Thu, 07 Jun 2007 13:25:19 -0400 (while OU was sucking), Eric Sosman
wrote:

>>>Ron Blancarte wrote On 06/07/07 13:08,:
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.

How do you tell the buffer's clients how large it is???? If you use
sizeof(outputBuffer) you're going to have trouble.

karl m

[Ron Blancarte]

On Thu, 07 Jun 2007 20:58:53 GMT (while OU was sucking), Karl Malbrain
wrote:

>"Ron Blancarte" <[e-mail] in message
news:0v********************************@4ax.com.. .

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

>>>On Thu, 07 Jun 2007 13:25:19 -0400 (while OU was sucking), Eric Sosman
wrote:
Ron Blancarte wrote On 06/07/07 13:08,:
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.

How do you tell the buffer's clients how large it is???? If you use
sizeof(outputBuffer) you're going to have trouble.

Yea, that I know. when defining the buffers, instead of using "100"
etc, they are constant defines. If the size needs to be checked, then
I will just check it against these define statesments.

RonB

[Ron Blancarte]

On Thu, 07 Jun 2007 16:26:16 -0400 (while OU was sucking), Eric Sosman
wrote:

>Ron Blancarte wrote On 06/07/07 14:39,:

>[...]
What problem that I am having is that it seems my functions which
worked with:

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

don't appear to be working with:

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

Of course this won't "work:" It won't even compile.
And if the first `inputBuffer' is really `outputBuffer',
then the buffer isn't big enough. We can sit here all
day trying to guess how to change what you've shown to
get to what your code is actually like, but in the end
that just means we're debugging our guesses and not
debugging your code.

That would be a typo as you pointed out.
unsigned char outputBuffer[200];
unsigned char *inputBuffer = outputBuffer + 100;

I'm not asking for you to post all umpty-bazillion
lines of your code (and I wouldn't read it if you did).
Whittle the code down to the smallest complete and
compilable program that demonstrates the problem, and
post that exact code: No paraphrases, no abbreviations,
no fill-in-the-blanks, but something another person can
run through his compiler unmodified. That way, we'll
be debugging your code instead of debugging a sort of
cloud of more and less likely possibilities centered
around your code.

If possible I would do this. Unfortunately what I am looking at here
is a 10000 line program that I need to change the memory footprint of
to add a new feature. The code runs in an in-house developed hardware
environment w/ two 8051 processors, to "Whittle the code down" would
still result in a large program.

I posted some function which utilize this code, mainly asking if,
syntactically they are correct. Clearly, I agree, my typo in the
above code was wrong, but in the thread of whittling down the code,
here it goes:

Given these declarations:

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

And this function:

void spi_getSize()
{
*((char*)&spiSize ) = inputBuffer[1];
*((char*)&spiSize+1) = inputBuffer[2];
}

if I changed my declarations to this:

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

Ignoring reading in data (which again was done via the SPI_receive
routine I posted earlier), should the spi_getSize function continue to
work as expected? (Which is reading in the 2nd and 3rd characters of
inputBuffer into an int).

RonB

[CBFalconer]

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

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Ron Blancarte wrote:

>

.... snip ...

>
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?

Who knows. You omitted the code. Cut your system down to
something compilable and executable that exhibits the problems
(about 100 lines or so) and post that. By then you probably have
solved it yourself.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Old Wolf]

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

*((char*)&spiSize ) = inputBuffer[1];
*((char*)&spiSize+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********@yahoo.comwrote in message
news:46***************@yahoo.com...

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********@yahoo.comwrote in message
news:46***************@yahoo.com...

>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_Keith) 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]:

>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 (&outputBuffer[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 (&outputBuffer[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.:

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