Groups | Search | Server Info | Login | Register


Groups > comp.unix.shell > #24886

Re: Command Languages Versus Programming Languages

From ram@zedat.fu-berlin.de (Stefan Ram)
Newsgroups comp.unix.shell, comp.unix.programmer, comp.lang.misc
Subject Re: Command Languages Versus Programming Languages
Date 2024-04-01 21:13 +0000
Organization Stefan Ram
Message-ID <stack-20240401220727@ram.dialup.fu-berlin.de> (permalink)
References <uu54la$3su5b$6@dont-email.me> <87edbtz43p.fsf@tudado.org> <types-20240401151149@ram.dialup.fu-berlin.de> <20240401111552.00006ddc@gmail.com> <20240401134457.000067f2@gmail.com>

Cross-posted to 3 groups.

Show all headers | View raw


John Ames <commodorejohn@gmail.com> wrote or quoted:
>And, in fact, C actually does one specific bit of automatic memory
>management itself - the stack, which may or may not even *be* a true
>hardware stack (depending on the architecture,) and which is handled in
>an entirely transparent fashion* by compiler-generated entry/exit code
>generated by the compiler for each function.

  This stack "management" is "limited" in C:

|Unfortunately, the notion of stack overflow is not mentioned
|by the standard or the standard’s rationale at all. This is
|very troublesome, as for most actual implementations stack
|overflow is a real problem.
...
|in a real C implementation, a call like f(10000000) will not
|return 10000000, but instead will crash with a message like
|"segmentation fault". Furthermore, stack overflow does not
|necessarily have to result in a crash with a nice error
|message, but might also overwrite non-stack parts of the
|memory (possibly putting the address of virus code there).
|Stack overflow even can occur without function calls. For
|example, the program int main(void) { int a[10000000]; }
...
"Subtleties of the ANSI/ISO C standard" (2012); Robbert
Krebbers, Freek Wiedijk; Radboud University Nijmegen.

Back to comp.unix.shell | Previous | Next | Find similar


csiph-web