«

Ico wrote:
> Michael Mair <> wrote:
>
>>OzBob wrote:
>>
<snip>
>>>
>>>Any advise / comments? Share and Enjoy, Ian
>>
>>
>>Yes: Compile with the highest warning level and in a standard C
>>mode. E.g.
>>
>>$ gcc -std=c99 -pedantic -W -Wall -O strstr.c -c
>
> <snipped a lot of warnings and errors>
>
>>Your program does not compile -- so how can you expect us to
>>look at it?
>
> It *does* compile, if you only fix the line wraps, probably caused by
> the OT's newsreader software. These things do happen.

You are right; I could have looked into it more deeply.
I just saw the missing of #include <string.h> and a "void main"
and just fed the whole thing to the compiler (as the OP claimed
to have used a "C99 compatible compiler") and pasted its output.
However, this was to illustrate the point that code which does
not meet minimum requirements may be ignored by the regulars...

The attempts at improvement speak for the OP, so the regulars
are motivated to put more effort into the reply (which was the
intention -- either save us all time or prove that it's worth
it).


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

OzBob wrote:
> "Michael Mair" <> wrote in message
> news:...
>
>>OzBob wrote:
>>
>>>I am developing some basic string / file manipulation C progams at home
>>>(Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
>>>running HP-UX 11.11 and c99 compatible compiler). However I seem to have
>>>encountered problems performing the most basic of manipulations and
>>>comparisons.
>>>
>>>I have posted my test code below, and the results I get on each compiler.
>>>The crux of the matter is that the 'strstr' function differs wildly in
>>>its behaviour on different platforms, and precious few man pages will
>>>actually provide a worked example of any function, let alone this one. I
>>>have had to write the "has_slash" function and use the reserved work
>>>SLASH already, to get around the problems that strstr() gives me.
>>>
>>>I know C is touted as an standardised development environment that
>>>provides portability (the immortal phrase "we converted to another
>>>platform by typing 'make'" springs to mind); I'm not seeing that right
>>>now.
>>>
>>>Any advise / comments? Share and Enjoy, Ian
>>
>>
>>Yes: Compile with the highest warning level and in a standard C
>>mode. E.g.
>>
>>$ gcc -std=c99 -pedantic -W -Wall -O strstr.c -c
>>strstr.c: In function `has_slash':
>>strstr.c:9: warning: comparison between pointer and integer
>>strstr.c: At top level:
>>strstr.c:24: warning: return type of 'main' is not `int'
>>strstr.c: In function `main':
>>strstr.c:35: warning: implicit declaration of function `strcpy'
>>strstr.c:36: warning: implicit declaration of function `strstr'
>>strstr.c:36: error: missing terminating " character
>>strstr.c:37: error: stray '\' in program
>>strstr.c:37: error: `slash' undeclared (first use in this function)
>>strstr.c:37: error: (Each undeclared identifier is reported only once
>>strstr.c:37: error: for each function it appears in.)
>>strstr.c:37: error: parse error before "n"
>>strstr.c:36: warning: empty body in an if-statement
>>strstr.c:37: error: missing terminating " character
>>strstr.c:38: error: `n' undeclared (first use in this function)
>>strstr.c:38: error: missing terminating " character
>>strstr.c:39: error: missing terminating " character
>>
>>where the include directive is on line 1.
>>
>>Your program does not compile -- so how can you expect us to
>>look at it?
>>
<snip>
> Micheal,

I'm not that Irish

> Have submitted the commands for gcc, with the following response. Have also
> checked the code and string.h is not included. I have since modified the
> comments at the end, included the <string.h> library at the start, and
> succesfully compiled using the commands provided. I even went a step further
> and removed the "-c" option from the command string to generate "a.out",
> which (in the interests of consistency) fails at the same point with the
> same error.
>
> I figure its the strstr command and the assignment of a pointer, which
> again, works fine on the HP-UX 'cc' compiler (the full one, not the inbuilt
> kernel-only one) with the '-AC99' c99 compatibility option, yet bails on the
> gcc compiler.
>
> Any further ideas? Share and Enjoy, OzBob
>
> /* original compiler output */
> # gcc -std=c99 -pedantic -W -Wall -O test.c -c
> test.c:24: warning: return type of `main' is not `int'
> test.c: In function `main':
> test.c:35: warning: implicit declaration of function `strcpy'
> test.c:36: warning: implicit declaration of function `strstr'
> test.c:53:1: unterminated comment
>
> /* included <string.h>, terminated comment */
> # gcc -std=c99 -pedantic -W -Wall -O test.c
> test.c:25: warning: return type of `main' is not `int'

Note: This is not to be taken lightly -- in principle, all
bets are off for a "void main" main().

> ls # -l a.out
> -rwxr-xr-x 1 root other 7280 Jan 15 15:04 a.out
> # ./a.out
> In function - i = 6
> Has slash = true
> By self- not found slash
> Segmentation Fault - core dumped
> #
<snip>

Look at this one; it is yours with slight changes and works
as I expect:

#include <stdio.h>
#include <string.h>

#define SLASH "/"

int has_slash (const char *in_str);

int main (void)
{
int test_true;

test_true = has_slash("copy /f file");
if (test_true != 0)
printf("Has slash = true\n");

/* New test, strstr results */
char *str_result;
char test_date[24];

strcpy(test_date, "02_04_2005");
if (strstr(test_date, SLASH) != NULL)
printf(" By self- found slash\n");
else
printf(" By self- not found slash\n");

str_result=strstr(test_date, "/");

if (str_result != NULL)
printf("Found slash: %s[%s]\n",
str_result, test_date);
if (str_result == NULL)
printf("Not found slash: \'\\0\'[%s]\n",
test_date);

return 0;
}

int has_slash (const char *in_str)
{
int i=0;

while (in_str[i] != *SLASH && in_str[i] != '\0'
/* && i < 100 */)
i++;

/* wrong format */
i = (in_str[i] != *SLASH) ? 0 : i+1;

printf("In function - i = %i\n", i);

return(i);
}

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

"OzBob" <> writes:
> I am developing some basic string / file manipulation C progams at home
> (Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
> running HP-UX 11.11 and c99 compatible compiler). However I seem to have
> encountered problems performing the most basic of manipulations and
> comparisons.
>
> I have posted my test code below, and the results I get on each compiler.
> The crux of the matter is that the 'strstr' function differs wildly in its
> behaviour on different platforms, and precious few man pages will actually
> provide a worked example of any function, let alone this one. I have had to
> write the "has_slash" function and use the reserved work SLASH already, to
> get around the problems that strstr() gives me.
>
> I know C is touted as an standardised development environment that provides
> portability (the immortal phrase "we converted to another platform by typing
> 'make'" springs to mind); I'm not seeing that right now.
>
> Any advise / comments? Share and Enjoy, Ian
>
> #include <stdio.h>
>
> #define SLASH "/"
>
> int has_slash(char in_str[24])
> {
> int i=0;
>
> while (in_str[i] != *SLASH && in_str[i] != NULL && i < 100) i++;
[snip]

What is the point of the SLASH macro? (It's a macro, not a reserved
word.) Delete the macro, change each occurrence of *SLASH to '/', and
change all other occurrences of SLASH to "/".

That won't fix your problem, but it will clean up some clutter and
make it easier to see the real problems.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Michael Mair <> writes:
> OzBob wrote:
[...]
>> # gcc -std=c99 -pedantic -W -Wall -O test.c
>> test.c:25: warning: return type of `main' is not `int'
>
> Note: This is not to be taken lightly -- in principle, all
> bets are off for a "void main" main().

In principle, yes. But in fact, I've never seen a C compiler that
misbehaves really badly given a "void main" declaration. The worst
I've seen is that the main program returns some arbitrary status to
the calling environment, equivalent to
int main(void) { .... return garbage; }

Having said that, "void main()" does invoke undefined behavior (unless
the implementation specifically documents it), and you should correct
it to "int main(void)" *before* you try to figure out what else is
going wrong. Most likely it won't make any real difference, and
you'll have one less thing to worry about.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

OzBob wrote:
> [...]
> int has_slash(char in_str[24])

Nobody seems to have mentioned it, but if in_str is
a string (that is, a char array with a '\0' terminator,
rather than an array of arbitrary form), you should
consider using the strchr() function instead of this
rather convoluted and confused mess. C.f. the Seventh
Commandment at

http://www.lysator.liu.se/c/ten-commandments.html

--
Eric Sosman
lid

Keith Thompson said:

> Michael Mair <> writes:
>> OzBob wrote:
> [...]
>>> # gcc -std=c99 -pedantic -W -Wall -O test.c
>>> test.c:25: warning: return type of `main' is not `int'
>>
>> Note: This is not to be taken lightly -- in principle, all
>> bets are off for a "void main" main().
>
> In principle, yes. But in fact, I've never seen a C compiler that
> misbehaves really badly given a "void main" declaration.

If you're prepared to generalise this to "given a declaration of main that
returns something other than int", I can vouch for the fact that I once
managed to crash Windows NT in a most colourful way by experimenting with
double main(void)!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

On 2006-01-15, Chris Torek <> wrote:
> In article <dqdgi7$ctk$>
> OzBob <> wrote:
>>I am developing some basic string / file manipulation C progams at home
>>(Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
>>running HP-UX 11.11 and c99 compatible compiler). However I seem to have
>>encountered problems performing the most basic of manipulations and
>>comparisons.
>
> Actually, your immediate problem is with the line:
>
> printf("some text including the %s directive\n", (char *)NULL);
>
> which is not a valid operation: the effect of providing NULL to
> the "%s" directive is undefined. On the HP-UX machine, the actual
> effect turns out to be a no-op, and on the SPARC, it turns out to
> be "Segmentation Fault - core dumped".

more data points: On glibc, freebsd, and 7th edition UNIX, it's
"(null)" - i'm surprised this wasn't codified into the standard, given
its age.

(note: 6th edition doesn't do this, either in the kernel or in iolib.
However, 6th edition unix didn't have the same I/O library - iolib
printf in 6th edition was called as, near as i can tell, any of the
following)

printf(-1, buf, format, args...);
printf(fd, format, args...); /* fd in 0..9 */
printf(format, args...); /* to stdout */

>On 2006-01-15, Chris Torek <> wrote:
>> Actually, your immediate problem is with the line:
>>
>> printf("some text including the %s directive\n", (char *)NULL);
>>
>> which is not a valid operation: the effect of providing NULL to
>> the "%s" directive is undefined. On the HP-UX machine, the actual
>> effect turns out to be a no-op, and on the SPARC, it turns out to
>> be "Segmentation Fault - core dumped".

In article <>
Jordan Abel <> wrote:
>more data points: On glibc, freebsd, and 7th edition UNIX, it's
>"(null)" - i'm surprised this wasn't codified into the standard, given
>its age.

The FreeBSD behavior is *my* doing: I wrote the stdio that was
released with "4.3-networking" (which is the root of all the free
BSDs). But I copied it from earlier Sun systems (rather than V7,
which I never used myself). Sun apparently lost this when they
converted to System V.

A number of "odd corners" of the Standard are basically kowtowing
to System V, which had very weird, arguably-broken semantics for
a number of edge cases.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

On 16 Jan 2006 01:02:31 GMT, Jordan Abel <> wrote
in comp.lang.c:

> On 2006-01-15, Chris Torek <> wrote:
> > In article <dqdgi7$ctk$>
> > OzBob <> wrote:
> >>I am developing some basic string / file manipulation C progams at home
> >>(Sparcstation running Solaris 9 and gcc) for my work environment (PA-RISC
> >>running HP-UX 11.11 and c99 compatible compiler). However I seem to have
> >>encountered problems performing the most basic of manipulations and
> >>comparisons.
> >
> > Actually, your immediate problem is with the line:
> >
> > printf("some text including the %s directive\n", (char *)NULL);
> >
> > which is not a valid operation: the effect of providing NULL to
> > the "%s" directive is undefined. On the HP-UX machine, the actual
> > effect turns out to be a no-op, and on the SPARC, it turns out to
> > be "Segmentation Fault - core dumped".
>
> more data points: On glibc, freebsd, and 7th edition UNIX, it's
> "(null)" - i'm surprised this wasn't codified into the standard, given
> its age.

I'd be very surprised if it had been. What arguments can you provide
that this would be a Good Thing(tm)?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

"Richard Heathfield" <> wrote in message
news:dqeo0l$i11$...
> Keith Thompson said:
>
>> Michael Mair <> writes:
>>> OzBob wrote:
>> [...]
>>>> # gcc -std=c99 -pedantic -W -Wall -O test.c
>>>> test.c:25: warning: return type of `main' is not `int'
>>>
>>> Note: This is not to be taken lightly -- in principle, all
>>> bets are off for a "void main" main().
>>
>> In principle, yes. But in fact, I've never seen a C compiler that
>> misbehaves really badly given a "void main" declaration.
>
> If you're prepared to generalise this to "given a declaration of main that
> returns something other than int", I can vouch for the fact that I once
> managed to crash Windows NT in a most colourful way by experimenting with
> double main(void)!

Ah - the '!' invokes undefined behaviour.