Thread: Comparing Strings

  1. #16
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Quote Originally Posted by Salem View Post
    > 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
    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 */
    }
    Yeah I know there are only 10 red comments, I left 2 off to assist with further reading.
    Well at least he got the declaration line right .
    1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
    2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
    3. Get rid of conio.h and other antiquated DOS crap headers.
    4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

  2. #17
    Registered User GL.Sam's Avatar
    Join Date
    Aug 2009
    Posts
    88
    >/* \n or fflush(stdout) needed */
    Wrong.
    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.
    C99 Standard

    >/* 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.
    Last edited by GL.Sam; 05-09-2010 at 04:58 PM.
    The only good is knowledge and the only evil is ignorance.
    ~Socrates

  3. #18
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  4. #19
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by GL.Sam View Post
    >/* \n or fflush(stdout) needed */
    Wrong.

    C99 Standard
    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.
    Hope is the first step on the road to disappointment.

  5. #20
    Registered User GL.Sam's Avatar
    Join Date
    Aug 2009
    Posts
    88
    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"
    Last edited by GL.Sam; 05-10-2010 at 07:37 AM.
    The only good is knowledge and the only evil is ignorance.
    ~Socrates

  6. #21
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    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:
    Code:
    printf("fail");
    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.

    I don't mind being wrong, I'm just not wrong in this case.


    Quzah.
    Hope is the first step on the road to disappointment.

  7. #22
    Registered User GL.Sam's Avatar
    Join Date
    Aug 2009
    Posts
    88
    >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
    Code:
    printf("fail");
    gets(win);
    indeed has to display quoted string. I said "Wrong" not to deny the general case.
    Last edited by GL.Sam; 05-11-2010 at 08:43 AM.
    The only good is knowledge and the only evil is ignorance.
    ~Socrates

  8. #23
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Quote Originally Posted by c99
    When a stream is unbuffered, characters are intended to appear from the source or at the destination as soon as possible.
    Otherwise characters may be accumulated and transmitted to or from the host environment as a block.

    When a stream is fully buffered, characters are intended to be transmitted to or from the host environment as a block when a buffer is filled.

    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.
    First two sentences, anything other than unbuffered may delay the output of data from the program to the environment.

    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.


    Quote Originally Posted by c99
    At program startup, three text streams are predefined and need not be opened explicitly
    — standard input (for reading conventional input), standard output (for writing
    conventional output), and standard error (for writing diagnostic output).
    As initially opened, the standard error stream is not fully buffered;
    the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device.
    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.
    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.
    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;
    }
    And the results:
    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#$
    In interactive mode, all is as you argue to be true. The string does indeed appear without any further hints to flush stdout.
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  9. #24
    Registered User GL.Sam's Avatar
    Join Date
    Aug 2009
    Posts
    88
    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.
    The only good is knowledge and the only evil is ignorance.
    ~Socrates

  10. #25
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    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.
    Hope is the first step on the road to disappointment.

  11. #26
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Quote Originally Posted by GL.Sam View Post
    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.
    Uhm. No. This thread would be a waste of FAQ space. Salem clearly indicated the problems and you just jumped into a useless argument and got owned by two more experienced C programmers.

    No offence.
    1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
    2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
    3. Get rid of conio.h and other antiquated DOS crap headers.
    4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

  12. #27
    Registered User GL.Sam's Avatar
    Join Date
    Aug 2009
    Posts
    88
    >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.
    Last edited by GL.Sam; 05-11-2010 at 03:51 PM.
    The only good is knowledge and the only evil is ignorance.
    ~Socrates

  13. #28
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by GL.Sam View Post
    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 ....honest....
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 04-29-2009, 10:13 AM
  2. Problem with comparing strings!
    By adrian2009 in forum C Programming
    Replies: 2
    Last Post: 02-28-2009, 10:44 PM
  3. comparing strings using argv
    By eth0 in forum C Programming
    Replies: 2
    Last Post: 09-20-2005, 09:20 AM
  4. comparing strings
    By infinitum in forum C++ Programming
    Replies: 1
    Last Post: 05-03-2003, 12:10 PM
  5. Comparing Strings
    By Perica in forum C++ Programming
    Replies: 6
    Last Post: 02-12-2003, 11:41 PM