stristr

[JohnF]

I don't know if this has been asked before but, it would be handy to have 'stristr' as pat of the PellesC standard library. I don't know why the standards committee has not included it.

John

[frankie]

I agree John, I haven't asked yet, but I put a remark in my webserver sample code.
It would also be nice to have the fcloseall() M$ historical function.

[Pelle]

I don't know if this has been asked before but, it would be handy to have 'stristr' as pat of the PellesC standard library.

Yes, probably useful. Since it's not part of Standard C and, as far as I can tell, not part of Posix or the Microsoft runtime, it would be a very private extension - only useful in Pelles C. Not sure how good this is...

If portability is not a big issue, there is always the Windows function StrStrI() - in shlwapi.h.

Pelle

[Pelle]

It would also be nice to have the fcloseall() M$ historical function.

Right - I have missed this case. Will be added...

Pelle

[frankie]

It would also be nice to have the fcloseall() M$ historical function.

Right - I have missed this case. Will be added...

Pelle

Thanks Pelle, could you also revise the addin.h becouse the constants for the AddIn_FindSourceText (FR_DOWN and FR_MATCHCASE) are not defined.
About the stristr function even though it is not part of the standard could be found it in many compilers. Anyway it is not a big issue unless when porting code.

[JohnF]

I don't know if this has been asked before but, it would be handy to have 'stristr' as pat of the PellesC standard library.

Yes, probably useful. Since it's not part of Standard C and, as far as I can tell, not part of Posix or the Microsoft runtime, it would be a very private extension - only useful in Pelles C. Not sure how good this is...

Pelle

Doesn't GCC use it? Anyway, it is useful!

This seems to be a common implimentation of it.

Code: [Select]


char * _stristr(const char * szSrc, const char * cszSrch)
{
const int nLength = strlen(cszSrch);
while(*szSrc)
{
if(!_strnicmp(szSrc, cszSrch, nLength))
break;
szSrc++;
}

if(!(*szSrc))
return NULL;
else
return (char*)szSrc;
}


John

[Pelle]

Thanks Pelle, could you also revise the addin.h becouse the constants for the AddIn_FindSourceText (FR_DOWN and FR_MATCHCASE) are not defined.

They are defined in commdlg.h - but the help file should say so.

About the stristr function even though it is not part of the standard could be found it in many compilers. Anyway it is not a big issue unless when porting code.

Always as an extension, AFAIK. I guess this is part of the problem - if I start adding various compiler extensions, the C library will quickly become very large and complex.

Pelle

[Pelle]

Doesn't GCC use it? Anyway, it is useful!

I think they have strcasestr - as a GNU extension.

This seems to be a common implimentation of it.

OK, thanks.

One problem is that there are still some standard C functions missing (complex math). There are probably more Posix functions to add. Maybe something Microsoft specific too. Adding extension on top of that - I just don't know. I don't want the C runtime to grow *too* big...

Pelle

[JohnF]

Doesn't GCC use it? Anyway, it is useful!

I think they have strcasestr - as a GNU extension.

This seems to be a common implimentation of it.

OK, thanks.

One problem is that there are still some standard C functions missing (complex math). There are probably more Posix functions to add. Maybe something Microsoft specific too. Adding extension on top of that - I just don't know. I don't want the C runtime to grow *too* big...

Pelle

Ok, you must do what you think is best.

John

[Pelle]

I have been thinking... maybe more consistent to add the following functions after all: _stristr, _strichr, _strrichr, _memichr (and the Unicode variations: _wcsistr, _wcsichr, _wcsrichr and _wmemichr). No compatibility names since there is not much to be compatible with...

If the functionality is present, it should easy to define a macro with the name of the function to be compatible with (strcasestr, strstri, istrstr...).

Pelle

[JohnF]

I have been thinking... maybe more consistent to add the following functions after all: _stristr, _strichr, _strrichr, _memichr (and the Unicode variations: _wcsistr, _wcsichr, _wcsrichr and _wmemichr). No compatibility names since there is not much to be compatible with...

If the functionality is present, it should easy to define a macro with the name of the function to be compatible with (strcasestr, strstri, istrstr...).

Pelle

Good thinking!    =D>

John

[Mikehg]

This seems to be a common implimentation of it.

Code: [Select]


char * _stristr(const char * szSrc, const char * cszSrch)
{
const int nLength = strlen(cszSrch);
while(*szSrc)
{
if(!_strnicmp(szSrc, cszSrch, nLength))
break;
szSrc++;
}

if(!(*szSrc))
return NULL;
else
return (char*)szSrc;
}


John

I was just recently toying with a new stristr for BCX.  What do you think about this version?

Code: [Select]


char *_stristr_(char *String, char *Pattern)
{
  int   mi=-1;
  while(Pattern[++mi])
   {
     if(String[mi]==0) return 0;
     if((String[mi]|32)!=(Pattern[mi]|32))
       { String++;  mi=-1; }
   }
  return String;
}


Mike H.

[JohnF]

Mike,

Using '32' is ok for us but I wonder weather it will be ok for all language locales. I don't  know enough about other language conditions to make an informed decision. Maybe someone else knows.

John

[Pelle]

If you use for example tolower(), you don't have to worry about it.

Pelle

[Mikehg]

Hi John and Pelle,

I had wondered about the local stuff, but couldn't really find any info that satisfied my questions  Since BCX trys to cater to many different compilers, I try to write the runtimes that work across all of them with similar performance.  Just for comparison, I had setup a small benchmark. Using the code above returned about .15 secs. Using tolower() had no significant diffference with PellesC, but with LCC-Win32, VC++ and others returned with greater than 1 sec. Makes you wonder what these other compilers have under the hood  Another good example was a replace function I tested once that uses strstr. One particular test only took millisecs with PellesC, and over 30 secs. with others!

Thanks,
Mike Henning