Write a program that uses function strcmp to compare two strings input by the user. The program should state whether the first string is less than, equal to or greater than the second string.
Printable View
Write a program that uses function strcmp to compare two strings input by the user. The program should state whether the first string is less than, equal to or greater than the second string.
No, you write a program that uses function strcmp to compare two strings input by the user. YOUR program should state whether the first string is less than, equal to, or greater than the second string.
Seriously, who posts crap like this and expects someone to do it for them?
Quzah.
here let me help you get started you will need something like this and ill leave the rest on to you
Code:
#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <string.h>
main()
{
char first[100],second[100];
printf("enter the first string :");
gets(first);
printf("enter the second string :");
gets(second);
if(strcmp(first,second)==0);
{
printf("the strings are equal");
}
getch();
}
mouse666666: cut down your example to a correct example of the use of strcmp. Your whole program is horribly wrong, and you managed to get the most relevant part wrong as well.
But others have already told you: wait for an attempt (or at least believable signs of an attempt) before you provide an example.
Wow - I counted 8 mistakes in mouse666666's attempt.
mouse666666, looks like another would disagree. I'll compare it to mine. Thank you for your help.
Code:
#include <stdio.h>
#include <string.h>
int main(void)
{
char str1[25]; /*initialize string 1*/
char str2[25]; /* initialize string 2*/
char c;
do
{
printf("Enter the first string:\n");
scanf("%s", &str1); /* reads string 1*/
printf("Enter the second string:\n");
scanf("%s",&str2); /* reads string 2*/
if(strcmp(str1, str2) >= 1) { /* compare strings if first string is greater than second */
printf("The first string is greater than the second string\n%s is greater than %s\n", str1, str2);
}
if(strcmp(str1, str2) <= -1){ /* compare strings if first string is less than second */
printf("The first string is less than the second string\n%s is less than %s\n", str1, str2);
}
if(strcmp(str1, str2) == 0){ /* compare strings if the strings are equal */
printf("The first string is equal to the second string\n%s is equal to %s\n", str1, str2);
}
printf( "Would you like another comparison? press y to continue:\n" );
scanf( "%s",& c );
} while(c=='y'||c=='Y');
return 0;
{
Instead of what I have, should the ending of the program look like this:
Is my error at the end when asking the user if they want to enter another comparison?
Another person told me to make sure to make the 'c' variable a character array of say 20 or so and then just compare the first character of the string. Like so:
char c[20];
/* code here */
scanf( "%s",&c );
}while(c[0]=='y'||c[0]=='Y');
Instead of using scanf, it would be easier to use getchar(), e.g.,
Alternatively, change %s to %c: the problem is now that the format specifier is that of a string, but you just want to read a char.Code:c = getchar();
A few other things to take note of:
- Instead of comparing against 1 and -1, compare against 0, e.g., strcmp(str1, str2) > 0.
- Store the result of strcmp in a variable.
- Make use of else.
- Indent your code more consistently.
mouse666666, I realise others have already called you on your errors here, but since I already took time to mention that gets is a bad idea (in this post) I would hate to see my work wasted. To recapitulate:Quote:
here let me help you get started you will need something like this and ill leave the rest on to you
Code:#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
#include <string.h>
main()
{
char first[100],second[100];
printf("enter the first string :");
gets(first);
printf("enter the second string :");
gets(second);
if(strcmp(first,second)==0);
{
printf("the strings are equal");
}
getch();
}
Read, and learn:
- cprogramming.com FAQ - Why gets() is bad/buffer overflows
- comp.lang.c C-FAQ - Why does everyone say not to use gets()?
- cpwiki FAQ - gets
And finally, from man 3 gets (Linux):
Now to aplst3:Quote:
Never use gets(). Because it is impossible to tell without knowing
the data in advance how many characters gets() will read, and
because gets() will continue to store characters past the end of
the buffer, it is extremely dangerous to use. It has been used to
break computer security. Use fgets() instead.
You had this:
Your code is prone to the same sort of problems you would have if you had used gets instead of scanf. (scanf can be a troublesome way to get input) Generally speaking, scanf will read in text until it reaches a space, or a width specifier. You did not specify a width, and so the only thing that will stop your call to scanf is when the input is a space. What happens if a line of text with 500 characters (but no spaces) is entered? All of a sudden, your char array of 25 length is overrun. You need to limit user input.Code:int main(void)
{
char str1[25]; /*initialize string 1 */
char str2[25]; /* initialize string 2 */
char c;
do {
printf("Enter the first string:\n");
scanf("%s", &str1); /* reads string 1 */
printf("Enter the second string:\n");
scanf("%s", &str2); /* reads string 2 */
Now I realise these are just toy programs for the purpose of learning, but why learn inherently troublesome ways to code? Anyway, there is a much more rock solid way of getting a line of text from the user, and you can read all about it here.
>scanf("%s", &str1);
Let's continue the quiz. :) Who's gonna tell me what's wrong with this?
since some of you told me there is 8 mistake. why dont you tell me the mistakes instead of saying WELL THERE IS 8 MISTAKES
There are probably more, but I'm unfamiliar with getch and conio and such.Code:#include <stdio.h>
#include <stdlib.h> //Unnecessary, nothing included from here, not an error though
#include <conio.h>
#include <string.h>
main() //main returns int
{
char first[100],second[100];
printf("enter the first string :");
gets(first); //don't use gets, for reasons already described
printf("enter the second string :");
gets(second);//same as above
if(strcmp(first,second)==0); //Notice the semi colon here
{
printf("the strings are equal"); //The string will print regardless of the if statement
}
getch();
//I would have said you forgot to return a value, but GL.Sam quoted the C standard about it in some other post and I'm inclined to believe him.
//Still, I'd imagine it's good practice.
}
Before posting code, you should be confident that it is correct so that you don't confuse people who are already confused (otherwise they wouldn't be posting).
Because if you don't make an attempt at figuring them out, you will come back here whenever you run into the same "mistake".
> why dont you tell me the mistakes instead of saying WELL THERE IS 8 MISTAKES
Because it was a challenge for you to look at your code and try to figure out where you screwed up. Like for example even compiling and testing it perhaps (re: the ; on the if).
I mis-counted (it was only a quick eyeball scan). It's up to 12 mistakes now
Yeah I know there are only 10 red comments, I left 2 off to assist with further reading.Code:#include <stdio.h>
#include <stdlib.h>
#include <conio.h> /* unnecessary non-standard header */
#include <string.h>
main() /* implicit declaration of main retuning int */
{
char first[100],second[100];
printf("enter the first string :"); /* \n or fflush(stdout) needed */
gets(first); /* NEVER use gets() - see the FAQ */
printf("enter the second string :");/* ditto above */
gets(second); /* ditto above */
if(strcmp(first,second)==0); /* ; makes if statement null */
{
printf("the strings are equal"); /* ditto above */
}
getch(); /* non-standard function - try getchar() */
/* undefined return value from main */
}
>/* \n or fflush(stdout) needed */
Wrong.
C99 StandardQuote:
When a stream is line buffered, characters are intended to be
transmitted to or from the host environment as a block when a new-line character is
encountered. Furthermore, characters are intended to be transmitted as a block to the host
environment when a buffer is filled, when input is requested on an unbuffered stream, or
when input is requested on a line buffered stream that requires the transmission of
characters from the host environment. Support for these characteristics is
implementation-defined, and may be affected via the setbuf and setvbuf functions.
>/* undefined return value from main */
Not undefined, since it anyway will have a return value due to implicit assuming of int. Return value would be 0. It differs from when main() is void.
How does that prove that the user will always see the line then?
I see a "Support for these characteristics is implementation-defined" next to all the words you've highlighted.
> Not undefined, since it anyway will have a return value due to implicit assuming of int.
Yeah, but WHAT value will that be?
Prior to C99, the environment gets a garbage value.
There is no substitute for saying what you mean.
You chose to bold the dumbest parts of that. You should have been paying attention to the parts you didn't bold:
Furthermore, characters are intended to be transmitted as a block to the host environment when ... and then you stopped. Why? Read and learn:
a buffer is filled
Didn't happen.
when input is requested on an unbuffered stream,
Who knows, maybe happened, maybe didn't.
or when input is requested on a line buffered stream that requires the transmission of characters from the host environment.
Same here. So the closest you get to proving "Wrong." is that maybe it's got buffers set just so. Maybe. There was no block sent, and no buffer was full, because as stated, there was no flush or newline call. So exactly what is it you think you're proving here?
"LOOK GUYZ, I HAZ STANDRD. CAN TEACH ME 2 READ IT?"
Quzah.
Salem
>Support for these characteristics is implementation-defined
Do you imply that one should take it as polite suggestions and the buffer may be implemented as to flush or not to flush when for example newline is encountered? Or when someone says "BIG BADA BOOM"? I just tried to show that gets() immediately after the printf() should flush the buffer causing visibility of the string prior to asking for input. As far as I'm aware, this condition applies to all modern implementations. I didn't mean that sole printf() without a newline or fflush() will do. I just wanted to extend this list to include situations of upcoming input.
quzah
"LOOK GUYZ IM A PRO SO STFU"
I didn't say I was a pro, and I didn't tell you to STFU. I said you need to actually understand what it is you're quoting. You obviously don't. There's nothing in the standard that says this line has to display:As such, the statement "\n of fflush needed" is accurate. It's not "Wrong." as you put it. Furthermore, all the parts you bolded were the irrelevant parts to the point you were trying to prove.Code:printf("fail");
I don't mind being wrong, I'm just not wrong in this case.
Quzah.
>printf("fail");
---
>I didn't mean that sole printf() without a newline or fflush() will do. I just wanted to extend this list to include situations of upcoming input.
You perhaps should learn to read yourself first. If you still don't have a clue I only say that this
indeed has to display quoted string. I said "Wrong" not to deny the general case.Code:printf("fail");
gets(win);
First two sentences, anything other than unbuffered may delay the output of data from the program to the environment.Quote:
Originally Posted by c99
Third sentence, see below; it typically applies when stdio from a program is redirected.
Fourth sentence, this refers to what most people regard as vanilla line buffered streams.
The fifth sentence onwards ("Furthermore...") has this large "implementation-defined" proviso attached to it.
So handy features like "stdout is automatically flushed when buffered stdin is requested" (the third bullet) simply may not apply.
Even where you have the feature, a call to setvbuf might cause it to be lost again.
The meaning of the last sentence being, that if it is an interactive device, then you don't know what kind of stream you have.Quote:
Originally Posted by c99
Most systems seem to go with line buffered (for both), but that doesn't help your argument.
Remember, your "interactive" program could easily end up being controlled as a child process at the end of a pipe (and not a terminal).
In such a case, the program would probably determine that input was NOT interactive, and drop into straight forward fully buffered mode.
Here's an experiment on my Ubuntu Linux.
And the results:Code:#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
printf("fail");
if ( argc > 1 && argv[1][0] == 'n' ) printf("\n");
if ( argc > 1 && argv[1][0] == 'f' ) fflush(stdout);
int c = getchar();
char ch = (char)c;
write(1,&ch,1);
return 0;
}
In interactive mode, all is as you argue to be true. The string does indeed appear without any further hints to flush stdout.Code:$ ./a.out
failq
q$
$ ./a.out n
fail
q
q$
$ ./a.out f
failq
q$
$ ./a.out < foo.c
#fail$
$ ./a.out n < foo.c
fail
#$
$ ./a.out f < foo.c
fail#$
The echo of the input always happens after the string.
If input is redirected however, things are different.
Without a hint to flush the output stream, the input is echoed BEFORE the supposed output.
Any correct program should produce the same output regardless of the exact nature of the input it is receiving.
Now imagine this was at the end of a pipe, and the controlling program was expecting to "see" your prompt (without a \n or a fflush) before sending more data. It's broken Jim.
Salem
Thank you for making this one clear. It was much better than quzah's meaningless flame. I'd vote for adding this topic to the FAQ board or something.
I'm awaiting your public apology to Salem. You see, when you show up and say "Wrong", and aren't, you should usually admit to being ... wait for it ... wrong!
I'm not opposed to adding this to the FAQ, but it's not like this idiot would have actually read it anyway.
Quzah.
>I'm awaiting your public apology to Salem.
>jumped into a useless argument
Without this argument I would have still been convinced in my view and I'm thankful for that. It wasn't useless. I'm just pursuing the truth. Did my posts look insulting? If so, I'm asking Salem to accept my sincere apologies for that.
But I am to jump in useless arguments of any sort and get owned by anyone if it helps someone on their way to knowledge.
Sometimes the only way to get anything out of these jerks is to set something on fire.
Just kidding. Anyway, you're right not to just cow to authority, including the authority of the herd. I've proven everyone wrong as an underdog here lots of times :p ....honest....