how can I write code to test a[100];

This is a discussion on how can I write code to test a[100]; within the C Programming forums, part of the General Programming Boards category; Originally Posted by zcrself Sometimes, when my program runs, there is a error "segmentation error", but I don't know why ...

  1. #16
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,720
    Quote Originally Posted by zcrself
    Sometimes, when my program runs, there is a error "segmentation error", but I don't know why and where is the error. I want to handle this error, but I don't know how to do handling.
    That indicates a programming error that should be fixed. As nimitzhunter noted, a debugger is suited to the task.

    Quote Originally Posted by zcrself
    java language has try-catch function,
    what does C language has?
    In standard C, accessing an array out of bounds results in undefined behaviour. There is no such exception handling feature. In the event that you use Java instead, you should still fix such programming errors rather than rely on them being handled somewhere by some exception handler.
    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

  2. #17
    Registered User
    Join Date
    Sep 2006
    Posts
    8,868
    java language has try-catch function,
    what does C language has?
    Smarter programmers!

  3. #18
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by zcrself View Post
    java language has try-catch function,
    what does C language has?

    Can "try-catch" function handle the error "segmentation fault"
    *Some* implementations of C have a __try __except and __try __finally construct.

    However, that's not what you want here. You want to set a variable of some kind with your array dimensions and then use that in your testing loops. If the array is expanded, change your dimensioning variables to suit.

    C does not do this automatically. As several people have already told you, what you want is NOT part of the language.

  4. #19
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,540
    For what it's worth, you could try this.

    Code:
    #include <stdio.h>
    #include <signal.h>
    #include <setjmp.h>
    
    sigjmp_buf env;
    
    void trap ( int sig )
    {
      write(1,"Caught!\n",8);
      siglongjmp(env,1);
    }
    
    int main()
    {
      struct  sigaction sa, oldsa;
      sa.sa_handler = trap;
      sigemptyset(&sa.sa_mask);
      sa.sa_flags = 0;
      int r = sigaction(SIGSEGV,&sa,&oldsa);
      if ( sigsetjmp(env,1) == 0 ) {
        int *p = NULL;
        *p = 0;
      } else {
        printf("Avoided the NULL dereference\n");
      }
      return 0;
    }
    
    
    $ ./a.out 
    Caught!
    Avoided the NULL dereference
    But your program was screwed when it made it's first out of bound memory access (but still within a valid page).

    Since it's been mentioned so many times already, let me repeat it.

    You need to DEBUG your code so it doesn't do these things. Not attempt some half-assed recovery mechanism when lots of damage has already been done. What is certain, there will be NO way to recover the damage done between the end of the array (you walked off the end of), and the end of the page it resides within.

    And it could be a hell of a lot of damage as well. Pages are allocated sequentially (most of the time), so you're only going to get the SIGSEGV when you walk off the end of the last allocated page.
    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.

  5. #20
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by Adak View Post
    Smarter programmers!
    Ooh...nice burn!
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  6. #21
    Registered User
    Join Date
    Jun 2005
    Posts
    6,295
    Quote Originally Posted by zcrself View Post
    java language has try-catch function,
    what does C language has?
    C has undefined behaviour

    Seriously, Java (more accurately, the Java virtual machine, not the language) imposes a runtime overhead on all programs, in order to detect buffer overruns.

    C is not associated with any virtual machine, so a C program is allowed to run over memory, without being forced to stay within array bounds. A segmentation fault (under unix) means the operating system has detected a program accessing some memory that it shouldn't. If the operating system does not detect such things (which is possible, as operating systems do not typically provide 100% coverage either of such things) they will remain undetected.

    The trade-off is one of performance versus need for programmer discipline. Java trades off performance in order to capture and report programmer errors. C relies on a programmer to do things right, but - if the programmer does things right - does not impose significant performance overhead.

    Note: despite marketing spiels suggesting Java is safe, it is actually technically possible for a buffer overrun to remain undetected in Java (to get a 100% guarantee, it would be necessary to sacrifice a lot more in terms of performance and other attributes). The only difference is that an overrun is more likely to be detected at the point it happens in Java, when compared with C.

    Quote Originally Posted by zcrself View Post
    Can "try-catch" function handle the error "segmentation fault"
    In C++, it cannot. In C, this is a meaningless question.

    Accessing data past the end of an array is undefined behaviour, in both C and C++. Once you're in the realms of undefined behaviour, there is no guarantee than any feature of the language is even usable. That includes exceptions: there is no means defined in the standard by which an invalid pointer operation causes any exception to be thrown.

    As noted above, the onus is on the C and C++ programmer to prevent or avoid instances of undefined behaviour, rather than relying on detection of such circumstances. For this reason, there is no standard means of detecting things like buffer overruns.
    Right 98% of the time, and don't care about the other 3%.

  7. #22
    -bleh-
    Join Date
    Aug 2010
    Location
    somewhere in this universe
    Posts
    454
    Quote Originally Posted by Adak View Post
    Smarter programmers!
    that is funny.
    "All that we see or seem
    Is but a dream within a dream." - Poe

  8. #23
    Registered User
    Join Date
    Aug 2009
    Posts
    168
    Quote Originally Posted by grumpy View Post
    C has undefined behaviour

    Seriously, Java (more accurately, the Java virtual machine, not the language) imposes a runtime overhead on all programs, in order to detect buffer overruns.

    C is not associated with any virtual machine, so a C program is allowed to run over memory, without being forced to stay within array bounds. A segmentation fault (under unix) means the operating system has detected a program accessing some memory that it shouldn't. If the operating system does not detect such things (which is possible, as operating systems do not typically provide 100% coverage either of such things) they will remain undetected.

    The trade-off is one of performance versus need for programmer discipline. Java trades off performance in order to capture and report programmer errors. C relies on a programmer to do things right, but - if the programmer does things right - does not impose significant performance overhead.

    Note: despite marketing spiels suggesting Java is safe, it is actually technically possible for a buffer overrun to remain undetected in Java (to get a 100% guarantee, it would be necessary to sacrifice a lot more in terms of performance and other attributes). The only difference is that an overrun is more likely to be detected at the point it happens in Java, when compared with C.


    In C++, it cannot. In C, this is a meaningless question.

    Accessing data past the end of an array is undefined behaviour, in both C and C++. Once you're in the realms of undefined behaviour, there is no guarantee than any feature of the language is even usable. That includes exceptions: there is no means defined in the standard by which an invalid pointer operation causes any exception to be thrown.

    As noted above, the onus is on the C and C++ programmer to prevent or avoid instances of undefined behaviour, rather than relying on detection of such circumstances. For this reason, there is no standard means of detecting things like buffer overruns.
    Thanks for your answer so that I understand C more clearly.

  9. #24
    Registered User
    Join Date
    Aug 2009
    Posts
    168
    Thanks a lot for a lot of senior programmers answering my questions eagerly.
    I learn C further for a newbie of C
    Last edited by zcrself; 12-26-2010 at 06:28 PM.

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

Similar Threads

  1. how to write a C code that evaluates 7, 7, 7, 1 = 100
    By filanfistan in forum C Programming
    Replies: 8
    Last Post: 10-21-2005, 07:37 AM
  2. C++ Operator Overloading help
    By Bartosz in forum C++ Programming
    Replies: 2
    Last Post: 08-17-2005, 12:55 PM
  3. Replies: 3
    Last Post: 03-04-2005, 01:46 PM
  4. Some humour...
    By Stan100 in forum A Brief History of Cprogramming.com
    Replies: 8
    Last Post: 11-06-2003, 09:25 PM

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