Re: why this program is not crashing

Jens.Toerring_at_physik.fu-berlin.de
Date: 02/11/05 

Date: 11 Feb 2005 12:41:56 GMT

manoj1978@gmail.com wrote:

> Richard Bos wrote:
>> manoj1978@gmail.com wrote:
>>
>> > buf1,buf2 and buf3 are stored in stack,
>>
>> Possibly, but even if so...
>>
>> > so incrementing pointer to buf2 goes towards buf1 not buf3.
>>
>> ...there's no reason to assume that this is true in the general case.
> It
>> may be true for you, but that doesn't automatically make it true for
> the
>> OP or anyone else. Not all the world is a Microsoft boxlet.
>>
> If they are stored in stack,then the direction will be this.right? I am
> not talking about the distance.

No. Already your first assumption that things are stored on a stack
is not necessary true - variables could also be in registers only or
there might be even machines not having a simple, linear stack. More-
over, things might not only depend on the direction the stack on your
machine grows (there are two alternatives, and both are used on diff-
erent architctures), but the compiler is in no way obliged to store
variables in a sequence resembling the the sequence the variables are
defined in the C code. It may, for example, recognize that, due to
alignment reasons, it would have to leave holes between the variables
and thus reorder them to avoid that as far as possible. So making any
assuptions about the relative positions of variables is plain wrong.
It may work in a certain way on your machine when you compile with a
certain set of options, but already changing the compiler options could
change things dramatically.
                                   Regards, Jens 

-- 
  \   Jens Thoms Toerring  ___  Jens.Toerring@physik.fu-berlin.de
   \__________________________  http://www.toerring.de

Relevant Pages

  • Re: Linux "NULL pointer dereferece" in the News...
    ... a reason (maybe a bad reason, maybe a good one, but the compiler can't possibly ... There has got to be a fundamental compiler bug here, ... and it is absurd to go adding compiler options that say "Oh, by the way, ...
    (Fedora)
  • Re: Linux "NULL pointer dereferece" in the News...
    ... a reason (maybe a bad reason, maybe a good one, but the compiler can't possibly ... There has got to be a fundamental compiler bug here, ... and it is absurd to go adding compiler options that say "Oh, by the way, ...
    (Fedora)
  • Re: Linux "NULL pointer dereferece" in the News...
    ... a reason (maybe a bad reason, maybe a good one, but the compiler can't possibly ... There has got to be a fundamental compiler bug here, ... and it is absurd to go adding compiler options that say "Oh, by the way, ...
    (Fedora)
  • Re: va_args (va_start, va_end, va_list ) souce?
    ... Wind River Compiler for PPC and it uses registers for the first seven ... As others so helpfully pointed out, that is the reason the _va macros are ... arguments through stack. ... The macros dealing with accessing ...
    (comp.arch.embedded)
  • Re: Array subsetting
    ... Others have pointed out the likely reason that you are getting stack ... arrays must be the same shape (well, I assume there's a requirement like ... compiler to create a temporary array for something quite that simple. ...
    (comp.lang.fortran)