NO

Author Topic: stristr  (Read 19662 times)

JohnF

  • Guest
stristr
« on: September 07, 2005, 08:17:28 AM »
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

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2096
stristr
« Reply #1 on: September 07, 2005, 10:14:29 AM »
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.
It is better to be hated for what you are than to be loved for what you are not. - Andre Gide

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
Re: stristr
« Reply #2 on: September 07, 2005, 05:01:07 PM »
Quote from: "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...

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

Pelle
/Pelle

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
stristr
« Reply #3 on: September 07, 2005, 05:02:25 PM »
Quote from: "frankie"
It would also be nice to have the fcloseall() M$ historical function.

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

Pelle
/Pelle

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2096
stristr
« Reply #4 on: September 07, 2005, 05:32:50 PM »
Quote from: "Pelle"
Quote from: "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.
It is better to be hated for what you are than to be loved for what you are not. - Andre Gide

JohnF

  • Guest
Re: stristr
« Reply #5 on: September 07, 2005, 05:51:58 PM »
Quote from: "Pelle"
Quote from: "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

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
stristr
« Reply #6 on: September 07, 2005, 06:59:18 PM »
Quote from: "frankie"
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.

Quote from: "frankie"

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

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
Re: stristr
« Reply #7 on: September 07, 2005, 07:11:43 PM »
Quote from: "JohnF"
Doesn't GCC use it? Anyway, it is useful! :)

I think they have strcasestr - as a GNU extension.

Quote from: "JohnF"

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
/Pelle

JohnF

  • Guest
Re: stristr
« Reply #8 on: September 07, 2005, 09:22:54 PM »
Quote from: "Pelle"
Quote from: "JohnF"
Doesn't GCC use it? Anyway, it is useful! :)

I think they have strcasestr - as a GNU extension.

Quote from: "JohnF"

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

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
stristr
« Reply #9 on: September 07, 2005, 09:58:14 PM »
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
/Pelle

JohnF

  • Guest
stristr
« Reply #10 on: September 07, 2005, 10:33:58 PM »
Quote from: "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


Good thinking!    =D>

John

Mikehg

  • Guest
Re: stristr
« Reply #11 on: September 08, 2005, 12:15:27 AM »
Quote

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

  • Guest
stristr
« Reply #12 on: September 08, 2005, 06:37:09 AM »
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

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
stristr
« Reply #13 on: September 08, 2005, 03:45:58 PM »
If you use for example tolower(), you don't have to worry about it.

Pelle
/Pelle

Mikehg

  • Guest
stristr
« Reply #14 on: September 09, 2005, 02:39:29 AM »
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