Like Tree4Likes

I dont understand a piece of this code

This is a discussion on I dont understand a piece of this code within the C Programming forums, part of the General Programming Boards category; Originally Posted by laserlight It so happens that it works for you, but for me I get "LASERLIGHT@" (note the ...

  1. #16
    Registered User
    Join Date
    Jun 2011
    Posts
    30
    Quote Originally Posted by laserlight View Post
    It so happens that it works for you, but for me I get "LASERLIGHT@" (note the '@').
    It should work.. Aah.. Maybe it's the compiler!!

  2. #17
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,976
    Quote Originally Posted by guitargod
    It should work.. Aah.. Maybe it's the compiler!!
    No, it is your compiler. Your compiler isn't wrong, but it doesn't make you right.

    If you disagree, quote the portions of the C standard that back your claim.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #18
    Registered User
    Join Date
    Jun 2011
    Posts
    30
    Okzz... Give up!

  4. #19
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,976
    Since I challenged you to quote the standard, I shall do the same. I don't have my copy of C99 at hand, but...
    Quote Originally Posted by C Standard Draft N1124 Clause 6.7.8 Paragraph 14
    An array of character type may be initialized by a character string literal, optionally enclosed in braces. Successive characters of the character string literal (including the terminating null character if there is room or if the array is of unknown size) initialize the elements of the array.
    Nothing is stated that backs your assertion that when "the siz eof the array is more than what we've filled, the compiler puts it in". In fact, it is stated that the null character is only included "if there is room".
    Salem and ArunS like this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #20
    Registered User
    Join Date
    Jun 2011
    Posts
    30
    You're right. It did work but the way I implemented it was improper..!
    I did this experiment a few months back and therefore was pretty confident about it!!

  6. #21
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,341
    The alleged 'proof'
    Code:
    #include<stdio.h>
    /*!!#include<conio.h>*/
    #include<string.h>
    int main()
    {
        char arr[10]={"LASERLIGHT"};
        printf("%s\n", &arr);
        strcat(arr, "ING");
        printf("%s\n", &arr);
        strcpy(arr, "WHITEFLAG");
        printf("%s\n", &arr);
    /*!!    getch(); */
        return 0;
    }
    
    $ gcc -g -W -Wall -ansi -pedantic baz.c
    baz.c: In function ‘main’:
    baz.c:7: warning: format ‘%s’ expects type ‘char *’, but argument 2 has type ‘char (*)[10]’
    baz.c:9: warning: format ‘%s’ expects type ‘char *’, but argument 2 has type ‘char (*)[10]’
    baz.c:11: warning: format ‘%s’ expects type ‘char *’, but argument 2 has type ‘char (*)[10]’
    First thing you need to do is get a decent compiler, then start paying attention to all warning and error messages. Using &array for %s is one of those things which works by accident. Similar mistakes with other types would just blow up.

    I'm guessing with the conio.h and getch rubbish that you're still using TurboC. Aside from it's age, it is also remarkably forgiving of memory trashing behaviour, especially in small programs. Hence the "it works for me" comments.

    But rest assured, your program is thoroughly broken.

    This is what I get, when trying to run your code using valgrind (look it up, start using it)
    Code:
    $ valgrind ./a.out
    ==2299== Memcheck, a memory error detector
    ==2299== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
    ==2299== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
    ==2299== Command: ./a.out
    ==2299== 
    LASERLIGHT
    LASERLIGHTING
    WHITEFLAG
    *** stack smashing detected ***: ./a.out terminated
    ======= Backtrace: =========
    /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x50)[0x411f390]
    /lib/tls/i686/cmov/libc.so.6(+0xe233a)[0x411f33a]
    ./a.out[0x804853d]
    /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x4053bd6]
    ./a.out[0x8048411]
    ======= Memory map: ========
    04000000-0401b000 r-xp 00000000 08:15 138613     /lib/ld-2.11.1.so
    0401b000-0401c000 r--p 0001a000 08:15 138613     /lib/ld-2.11.1.so
    0401c000-0401d000 rw-p 0001b000 08:15 138613     /lib/ld-2.11.1.so
    0401d000-0401f000 rw-p 00000000 00:00 0 
    0401f000-04020000 r-xp 00000000 08:15 207043     /usr/lib/valgrind/vgpreload_core-x86-linux.so
    04020000-04021000 r--p 00000000 08:15 207043     /usr/lib/valgrind/vgpreload_core-x86-linux.so
    04021000-04022000 rw-p 00001000 08:15 207043     /usr/lib/valgrind/vgpreload_core-x86-linux.so
    04022000-04028000 r-xp 00000000 08:15 207048     /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so
    04028000-04029000 r--p 00006000 08:15 207048     /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so
    04029000-0402a000 rw-p 00007000 08:15 207048     /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so
    0402a000-0402b000 rw-p 00000000 00:00 0 
    0403d000-04190000 r-xp 00000000 08:15 138819     /lib/tls/i686/cmov/libc-2.11.1.so
    04190000-04191000 ---p 00153000 08:15 138819     /lib/tls/i686/cmov/libc-2.11.1.so
    04191000-04193000 r--p 00153000 08:15 138819     /lib/tls/i686/cmov/libc-2.11.1.so
    04193000-04194000 rw-p 00155000 08:15 138819     /lib/tls/i686/cmov/libc-2.11.1.so
    04194000-04199000 rw-p 00000000 00:00 0 
    04199000-04599000 rwxp 00000000 00:00 0 
    045ac000-045c9000 r-xp 00000000 08:15 132946     /lib/libgcc_s.so.1
    045c9000-045ca000 r--p 0001c000 08:15 132946     /lib/libgcc_s.so.1
    045ca000-045cb000 rw-p 0001d000 08:15 132946     /lib/libgcc_s.so.1
    08048000-08049000 r-xp 00000000 00:15 148056     /home/sc/work/a.out
    08049000-0804a000 r--p 00000000 00:15 148056     /home/sc/work/a.out
    0804a000-0804b000 rw-p 00001000 00:15 148056     /home/sc/work/a.out
    0804b000-0804c000 rwxp 00000000 00:00 0 
    38000000-3819e000 r-xp 00000000 08:15 207047     /usr/lib/valgrind/memcheck-x86-linux
    3819f000-381a1000 rw-p 0019e000 08:15 207047     /usr/lib/valgrind/memcheck-x86-linux
    381a1000-38a77000 rw-p 00000000 00:00 0 
    61d9d000-62a1d000 rwxp 00000000 00:00 0 
    62a1d000-62a1f000 ---p 00000000 00:00 0 
    62a1f000-62a2f000 rwxp 00000000 00:00 0 
    62a2f000-62a31000 ---p 00000000 00:00 0 
    62a31000-64f83000 rwxp 00000000 00:00 0 
    beb36000-beb38000 rwxp 00000000 00:00 0 
    bfb24000-bfb39000 rw-p 00000000 00:00 0          [stack]
    ==2299== 
    ==2299== HEAP SUMMARY:
    ==2299==     in use at exit: 53 bytes in 1 blocks
    ==2299==   total heap usage: 6 allocs, 5 frees, 989 bytes allocated
    ==2299== 
    ==2299== LEAK SUMMARY:
    ==2299==    definitely lost: 0 bytes in 0 blocks
    ==2299==    indirectly lost: 0 bytes in 0 blocks
    ==2299==      possibly lost: 0 bytes in 0 blocks
    ==2299==    still reachable: 53 bytes in 1 blocks
    ==2299==         suppressed: 0 bytes in 0 blocks
    ==2299== Rerun with --leak-check=full to see details of leaked memory
    ==2299== 
    ==2299== For counts of detected and suppressed errors, rerun with: -v
    ==2299== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 14 from 9)
    Aborted
    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.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  7. #22
    Registered User
    Join Date
    Jun 2005
    Posts
    5,871
    Quote Originally Posted by guitargod View Post
    You're right. It did work but the way I implemented it was improper..!
    And it is not guaranteed to work with another compiler, with different compilation options, etc etc.

    That is not a fault of your compiler, or even other of compilers that would cause your code to malfunction. It is a fault in your code.

    Quote Originally Posted by guitargod View Post
    I did this experiment a few months back and therefore was pretty confident about it!!
    And laserlight, having understood what the standard says, was (and is) able to be 100% certain you were mistaken.

    "100% certain" trumps "pretty confident", any way you look at it.
    Right 98% of the time, and don't care about the other 3%.

  8. #23
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,266
    Quote Originally Posted by guitargod
    Proof
    Proof of something alright... something about level of ignorance, or ability to troll!

    If you're not experienced enough to figure out what really happens when you don't leave room for the null terminator that it puts out of bounds from that array, then that's you're problem. Good luck tracking down the problem when the bug occurs in a real program. Maybe then you'll learn.

    You're wrong - end of story. If you don't stop and listen immediately then you are a troll and will be dealt with one way or another.
    Last edited by iMalc; 06-13-2011 at 12:46 AM.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  9. #24
    Registered User
    Join Date
    Jun 2011
    Posts
    30
    Sorry grumpy, iMalc, laserlight!

  10. #25
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by guitargod View Post
    Code:
    #include<stdio.h>
    #include<conio.h>
    #include<string.h>
    int main()
    {
        char arr[10]={"LASERLIGHT"};
        printf("%s\n", &arr);
        strcat(arr, "ING");
        printf("%s\n", &arr);
        strcpy(arr, "WHITEFLAG");
        printf("%s\n", &arr);
        getch();
        return 0;
    }
    Output-
    LASERLIGHT
    LASERLIGHTING
    WHITEFLAG
    ...
    Now you're messing with array bounds errors... writing stuff to memory you don't "own". This is both bad practice and asking for problems...
    What is in the 3 characters you went past the end of the array? What other data have you overwritten?

    Yes on trivial examples like the one above you may get away with it, but you absolutely don't want to do that in any program of greater complexity... You create wonderful situations like... "I changed the name of the #3 Widget to Golden Widget and now it says we have 347,569 bowling balls in stock...."

    C absoltly does not baby sit or correct sloppy programming. That is your job as a programmer.

  11. #26
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,341
    I think we're done here.
    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.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 05-03-2011, 12:29 AM
  2. i dont understand bit
    By joker_tony in forum C Programming
    Replies: 2
    Last Post: 03-27-2008, 12:15 AM
  3. need help to understand a piece of code
    By rraajjiibb in forum C Programming
    Replies: 3
    Last Post: 08-09-2004, 11:18 PM
  4. What I dont understand...
    By nomi in forum C# Programming
    Replies: 7
    Last Post: 01-20-2004, 01:00 AM
  5. dont understand VS.NET
    By Qui in forum Windows Programming
    Replies: 6
    Last Post: 10-15-2003, 07:36 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21