stringslib

[janni]

Motivated and helped by Florin, I've prepared a replacement for the strings library (without undue pride it's much smaller and faster than the original) during which job some funny things were discovered:

1. memmove procedure, in spite of what is stated in help, does not ensure that "bytes in p2 are copied to p1 before being overwritten". Simple example of memmove(@st+1,@st,5) where st='01234...', gives 011234 instead of 001234.

2. StrAppendPre does not work properly. In a sample code the procedure blundered for c.a. 9000 cycles doing nothing.

Code: Select all

data1:='     6767678';
StrAppendPre(data1,'5');

3. StrRChr gives result smaller by 1 than it should:

Code: Select all

data1:='5     6767678';
aa:=StrRChr(data1,'6');

gives aa=9 instead of 10 (there are 5 spaces in the input string).

4. StrnCpy sometimes produces string without terminating byte 0. Example:

Code: Select all

data1:='12345';
data2:='67';
StrnCpy(data1,data2,2);

5. strstr result is undetermined, if first string is empty. (Confirmed with asm code check.)

This is naturally just what I've spotted while comparing functioning of both libraries. There may be more...

P.S. There are also mistakes in help, like strpbrk being function (not procedure) and result of strcmp being integer (not byte).

[zristic]

Note taken, thanks for the post. We will analyze this thoroughly.

[srdjan]

Motivated and helped by Florin, I've prepared a replacement for the strings library (without undue pride it's much smaller and faster than the original) during which job some funny things were discovered:

1. memmove procedure, in spite of what is stated in help, does not ensure that "bytes in p2 are copied to p1 before being overwritten". Simple example of memmove(@st+1,@st,5) where st='01234...', gives 011234 instead of 001234.

- only for pic18. Fixed.

2. StrAppendPre does not work properly. In a sample code the procedure blundered for c.a. 9000 cycles doing nothing.

Code: Select all

data1:='     6767678';
StrAppendPre(data1,'5');

- Fixed.

3. StrRChr gives result smaller by 1 than it should:

Code: Select all

data1:='5     6767678';
aa:=StrRChr(data1,'6');

gives aa=9 instead of 10 (there are 5 spaces in the input string).

- I could not reproduce this one. Please send me a piece of code in a project like form that can be compiled, which demonstrates the issue you are talking about to srdjan@mikroe.com, along with the reference to this post.

4. StrnCpy sometimes produces string without terminating byte 0. Example:

Code: Select all

data1:='12345';
data2:='67';
StrnCpy(data1,data2,2);

- Well, you told the function to copy only first two element of data2 string into data1 string, so null character should not be copied. This is one of the standard C routines and as such it was implemented according to ANSI C standard.
It states:

The strnspy function copies not more than N characters (characters that follow a null character are not copied) from the array pointed to by s2 to the array pointed to by s1. If copying takes place between objects that overlap, the behavior is undefined.
If the array pointed to by s2 is a string that is shorter than N characters, null characters are appended to the copy in the array pointed to by s1, until N characters in all have been written.

Where s1, s2 and N are input parameters of the above mentioned routine.

This however

Code: Select all

StrnCpy(data1,data2,3);

should copy null character. It was not working and that is fixed now.

5. strstr result is undetermined, if first string is empty. (Confirmed with asm code check.)

- Fixed.

This is naturally just what I've spotted while comparing functioning of both libraries. There may be more...

P.S. There are also mistakes in help, like strpbrk being function (not procedure) and result of strcmp being integer (not byte).

- Fixed.

[janni]

It's a pleasure to have such an excellent feedback . The only thing that could make it even better would be immediate posting of the fixes in this forum.

I'll recheck point 3 and let you know.

[srdjan]

Hi,

... The only thing that could make it even better would be immediate posting of the fixes in this forum...

You know that our libraries are not open source. The best thing we could do is to upload the library .mcl files and give you link for download here. Also, if somebody needs updated libraries asap, all he should do is ask, we will send them by mail, as it has been the case so far. Thank you for understanding.

[janni]

Hi,
The best thing we could do is to upload the library .mcl files and give you link for download here.

That's exactly what I had in mind. Plus exe files when fixes concern the compiler.

[srdjan]

Hi,

Hi,
The best thing we could do is to upload the library .mcl files and give you link for download here.

That's exactly what I had in mind. Plus exe files when fixes concern the compiler.

I do not know about this one. Then users would have to search the forum in order to find newest compilers .exe files. In my opinion this would make great mess. Patches on our official download site would be better solution.

[janni]

I do not know about this one. Then users would have to search the forum in order to find newest compilers .exe files. In my opinion this would make great mess. Patches on our official download site would be better solution.

No, I only meant this forum users - to make the beta testing proces smoother we need as up-to date libs and execution files as possible. But a set of updated libs could indeed be available to all users.

[janni]

Hi srdjan,

There is no error in StrRChr - in my program I've used StrAppendPre directly before it and, as it didn't work, there was a difference between results when using our and official library. Sorry for false alarm.