topic Re: Problem with strpbrk in Operating System - Linux

Problem with strpbrk

Fred Vogel — Thu, 05 Jul 2007 17:14:44 GMT

Hi,

I'm having difficulty with strpbrk going into a recursive loop that explodes the stack. This is happened when I use my c++ compiler and not my c compiler. The application i'm building right now has be be built in c++.

I'm on an HP11.23v2 IA machine. 32 bit compiles. aCC A.06.13. For the life of me I cannot figure out why this is happening but know the problem has to be really easy and something i'm missing.

Thanks,
Fred

Re: Problem with strpbrk

A. Clay Stephenson — Thu, 05 Jul 2007 17:25:32 GMT

Without seeing your code it's a bit difficult to comment. I assume that both strings are actually NUL terminated and have not been stepped on by other code. I would output the string values just before the call to strpbrk. Note that this functions expects both of the strings to be const. Is this a multi-threaded program so that the strings might be being altered by another thread?

Re: Problem with strpbrk

Fred Vogel — Thu, 05 Jul 2007 18:11:29 GMT

Hello Clay,

Yes both strings are NULL terminated. It is single threaded and the debugger shows the strings clean going in. Both strings are const.

Thanks,
Fred

Re: Problem with strpbrk

Dennis Handly — Fri, 06 Jul 2007 04:06:05 GMT

Can you grep for strpbrk in /opt/aCC/include_std/*?

There are 3 or 4 C string functions that are required to be overloaded by the C++ Standard. It looks like strpbrk is one of them because of the broken C definition.

I would not expect them to fail unless you illegally had a macro like:
#define const
Or used the old cfront trick of -Dconst=.

>Clay: Note that this function expects both of the strings to be const.

That's not what "const" means. It means that the function doesn't modify them, so it allows const strings. And due to qualification conversion, a char* can be passed to a const char*.

Re: Problem with strpbrk

Fred Vogel — Fri, 06 Jul 2007 11:05:52 GMT

Hi Dennis,

>>Can you grep for strpbrk /opt/aCC/include_std/*?

Yes, I have been stareing at it for a day now, particularly in cstring. I ran the grep you asked, here is what it spit out:

cstring:#define strpbrk __strpbrk_keep_out
cstring:#undef strpbrk
cstring:#pragma builtin strpbrk
cstring:#pragma extern strchr, strpbrk, strrchr, strstr, memchr
cstring: extern "C" const char* strpbrk(const char *, const char *);
cstring: inline char* strpbrk(char *s, const char *p);
cstring: return const_cast (strpbrk(const_cast(s), p));
cstring:using ::strpbrk;
string.h:using std::strpbrk;

>>I would not expect them to fail unless you illegally had a macro like:
>>#define const
>>Or used the old cfront trick of -Dconst=.

I did find a #define const behind a #ifndef __STDC__ definition. I was worried that it might get picked up since i'm using the ++ compiler, so I deleted it. I rebuilt everything from scratch, same problem.

Is there any tusc or elfdump information that I could provide that would help?

Thanks,
Fred

Re: Problem with strpbrk

Fred Vogel — Fri, 06 Jul 2007 13:10:33 GMT

I have realized that i am having the same problem with strchr, which is guess is no big surprise.

Here are some things I think may be important. The code with strpbrk and strchr is in an archive library that was compiled in ansi c. The running program was compiled in c++ and linked with this .a file. I went ahead an made an all c++ version and still no joy.

Fred

Re: Problem with strpbrk

Fred Vogel — Fri, 06 Jul 2007 17:41:10 GMT

Dennis,

You hit the nail on the head. I did remove the offending #define const and kept having the problem. Turns out that the #define const was being autogenerated. Once I got rid of that...it worked like a charm!

Thanks
Fred

Re: Problem with strpbrk

Dennis Handly — Fri, 06 Jul 2007 21:42:11 GMT

>I did find a #define const behind a #ifndef __STDC__ definition.

So the proper test would be to use:
#if !defined(__STDC__) && !defined(__cplusplus)