Re: [Dev-C++] Problems with input

[Per W. <pw...@ia...>]

EMA System        email: pw...@ia...
Per Westermark    web: http://iapetus.neab.net
Vargvaegen 174B   phone: +46 70 214 74 48
S-906 42 Umeaa
Sweden


On Tue, 17 Jul 2007, Adam Jones wrote:

> >>Per Westermark wrote:
> >>No, the application will not crach for a str[10]; unless the target is an
> >>embedded system with extremely small stack - str[10] is smaller than "int
> >>a,b,c" on a 32-bit machine...
>
> You've missed my point completely. For that, I take the blame.......

No, I didn't miss the point. I just noted that there isn't a need to test
something that can't be tested (there). An auto-allocated str[] will
have an address without regard to if the OS has grown the stack yet or
not.

The OS will not grow the stack until the application tries to access the
variables, since the OS doesn't know how much stack the function uses. For
code wth more auto variables than what fits in a single memory page, the
compiler will have to insert a loop that sequentially touches a byte in
every required memory page, to make sure that the first access isn't
beyond the stack guard page.

I just see many tools in the toolbox. malloc() isn't the only tool
suitable for use with arrays. The avoidance of memory leaks and
fragmentation, and the excellent locality of reference makes auto
variables very good to use. When using very low-end embedded systems,
better compilers will normally create a static stack usage tree so the
developer will not have to spend too much time on figuring out worst-case
stack need besides any ISR.

>
> >> Don't assume that you know what I think is okay.
>
> I would never do that. All I do know is what you wrote. You wrote
>
> >>There are no pointer to test. If the
> >>allocation fails (the stack can't fit the variable) then the application
> >>will die.
>
> >From this statement that you made, I assumed that you did not see a point to
> checking if the allocation was not successful.
> But you made my point later when you stated:
>
> >>It is a good habit to always check a pointer retrieved from malloc() or
> >>new(), just as checking the result from all other functions that may fail.
>
> This was the only point I was trying to make. Nothing more or less....
>
> -Adam Jones
>
>