Re: why this program is not crashing

From: Flash Gordon (spam_at_flash-gordon.me.uk)
Date: 02/15/05

  • Next message: roman ziak: "Re: C portability is a myth" 
    Date: Tue, 15 Feb 2005 13:55:29 +0000

    manoj1978@gmail.com wrote:
    > ghyott@yahoo.com wrote:
    >
    >>hello,
    >>In my opinion the following code should crash when run with
    >>*(argv+1)="1234567890" and *(argv+2)="1234567890" .
    >
    >
    > It crashed when i ran this with microsoft visual c 7
    >
    >> int main(int argc,char **argv)
    >> {
    >> char buf1[5];
    >> char buf2[5];
    >> char buf3[5];
    >> strncpy(buf2,*(argv+1),sizeof(buf2));
    >> strncpy(buf3,*(argv+2),sizeof(buf3));
    >> sprintf(buf1,"%s",buf2);
    >> return 0;
    >> }
    >>
    >>The last element of buf2 is not NULL.Therefore sprintf should copy
    >>"1234512345"
    >>to buf1 and which should result in segmentation fault.However,this is
    >>not the case and the program is running normally.Can anybody please
    >>pin-point my error.
    >>
    >>Thanks
    >
    > buf1,buf2 and buf3 are stored in stack,so incrementing pointer to buf2
    > goes towards buf1 not buf3.if they were global then it will be as you
    > say.

    Maybe on your implementation, but in general it is whatever the compiler
    feels like doing. The compiler could see that main is not called
    recursively and therefore implement buf1, buf2 and buf3 as if they were
    static, it could reorder them, possibly on the basis of when they are
    used, it could add in sentinel values between them to allow for the
    detection of buffer overflows, or anything else it likes.

    > buf1,buf2 buf3 have padding to make them start in addresses divisible
    > by 4.so most possibly 3 bytes padding.

    Again, that may apply to your system but it is not true in general.

    > one of them may be zero by chance
    > that may be why it didn't crash in your system.

    Speculating why someone else's system does not crash on buffer overflow
    (or any other undefined behaviour) on the basis of you implementation is
    generally pointless. 

    -- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
  • Next message: roman ziak: "Re: C portability is a myth"

    Relevant Pages

    • Re: gets() is dead
      ... It is possible, though unfortunately not easy, to write a compiler that handles buffer overflows on getscorrectly and safely, by terminating the program with an error message. ... If it was trivial to use fgets() safely then peole wouldn't have had such trouble creating correct code. ... If you tell it to overrun the buffer by one, it may return a number out by a factor of ten, but it will probably crash, we can write a compiler that guarantees it will crash, and it is almost certainly better that it crash than that it calculate the wrong value. ...
      (comp.lang.c)
    • Re: How do I find where my application is crashing
      ... obvious when compiled as a Release build because of optimizations and ... Try reducing the compiler and linker optimization settings 1 by 1 ... > simply crashing but with no signs/details on where the crash is occuring. ... > server is running on a Win2K3 host. ...
      (microsoft.public.dotnet.general)
    • Re: security issues with forth
      ... sloppy, because they'll be taken care of. ... omniscient compiler" you are talking about. ... One crash and they get the point. ...
      (comp.lang.forth)
    • Re: Random crashes
      ... > out what is causing a random crash? ... code ("compiler warns about ... ... - Some libraries, including standard libraries, come with debugging ... versions or you can obtain some debugging version. ...
      (comp.lang.cpp)
    • Re: Article of interest: Python pros/cons for the enterprise
      ... Optimized C programs can crash when pointers walk off the ... Very rarely, say inside a loop, I temporarily change my default compiler ... because i might be aliased to something, but in a sane language it ...
      (comp.lang.python)