strstr confusion

[guest]

Hi all,

I have written the following test function to understand strstr():

[bluetooth]

The only thing you're doing wrong is misinterpreting the answer.... strstr returns a *pointer* to the occurence of the string, not the relative position of the occurence.

If you need the offset, use the source for strstr as a starting point and just return a counter.

Good luck....

[guest]

Thanks bluetooth for your reply.

I have read quite a bit about pointers but still find them difficult to use.

How would I go about getting the offset?

[bluetooth]

It's returning the pointer to the location of the string in s2...

If you just say:

[guest]

Many thanks bluetooth, works fine now. (V3.221)

Do you know of a good reference or tutorial for pointers using CCS?

[bluetooth]

Get Kernighan & Ritchie's "The C Programming Language"... it's the bible!

Pointers is pointers! CCS does them pretty much according to K&R with the exception of pointers to constants.

[guest]

Hi again,

I have been working on my code and have come to another stumbling block:

I am manipulating my own array and just add a 0x00 to the end (null) so I can use string functions like strstr().

I get strange results, so did some test with the previous little program I posted above.

What I get is:

test1() returns 4 (as expected)
test2() returns 238
test3() returns 0

I expected all 3 to return the value 4.

test2 is identical to test1 except for vars names
test3 uses my individually set array contents

Can anybody kindly explain what's wrong with my code or ist this a Compiler issue?

Thanks

My code:

[Mark]

Maybe its your compiler version. This is what I got:

[PCM programmer]

One problem is that he's taking the 16-bit pointer value returned by
the string function and he's stuffing it into an 8-bit char.

[guest]

Thanks for both your replies.

I have tried to use long vars now as in the new code below and still get the same problem:

test1() returns 4 (as expected)
test2() returns 65518
test3() returns 0

My compiler version is PCH 3.221

any other ideas apart from a compiler bug?

[Mark]

[PCM programmer]

[guest]

I have done some more tests:

- tried compiler versions 3.191, 3.221 and latest 3.222, all give the same wrong results, i.e.

test1: 4
test2: 238
tes3: 0

I then compiled the same above source for a 18F242 and bingo:

it works correctly, i.e.

test1: 4
test2: 4
test3: 4

So why woud I get the correct result when compiled for a 18F242 and wrong results when compiled for a 18F8720 ???

I guess the only difference is the header file *.h or are there any other differences within the compiler itself?

I'll have a look at the header files...

... don't I love this sort of thing ;-)

[guest]

One other thing I found was that as I commented the testx() calls out, the next one down would show the coorect result i.e.:

as before:

void main()
{
test1();
test2();
test3();
while(1)
{}
}

will give: 4 / 238 / 0

Next, commenting out the first call:

void main()
{
//test1();
test2();
test3();
while(1)
{}
}

will give: 4 / 0

And finally, commenting out the first two:

void main()
{
//test1();
//test2();
test3();
while(1)
{}
}

will give: 4

Looks as if always the first call causes subsequent calls to give incorrect results.

Just thought another symptom might spark an idea somewhere of what's happening here...

[Ttelmah]

First general comment, get out of the habit of using a variable to hold a pointer. Declare a pointer instead. Otherwise it makes it very likely that there will be a size problem, and this will 'come back to haunt you', if you move to other processors. So just declare the values as:
char *r;

For the first routine, and similarly for the latter routines. This then makes the code portable through the three possibilities so far (PCM/PCB, PCM/PCB, with #device *=16, and PCH). Yes PCH uses 16 bit pointers, this is why *=16, is redundant on these chips.

Now I have just compiled the code on 3.221, and it gives me correct results on both chips. Only two changes were implemented, I declared the values to hold the pointer results, as pointers, and I didn't use strcpy, but just declared the strings in the first two examples, with:
char s1[10] = "EF";
char s2[10] = "ABCDEF2;

Which makes the compiler initialise the strings for you.
I'd look very carefully through your code again. The answer '65518', could actually make sense, if the string declarations are incorrect, and the routine is searching through the entire possible 16bit address range, and then finding the requested string in the memory used by the routine 'before'.

Best Wishes