Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Command Languages Versus Programming Languages
Date: Mon, 01 Apr 2024 15:56:11 -0700
Organization: None to speak of
Lines: 35
Message-ID: <877chgr8tw.fsf@nosuchdomain.example.com>
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>
	<stack-20240401220727@ram.dialup.fu-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 01 Apr 2024 22:56:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3a6d60d87380a0c0f1e42919673cda47";
	logging-data="2906074"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19a1L9o96O/tf1bGTFzcFuc"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:R6C/cow9/gWiNCjsAo3xx7I5nXg=
	sha1:bbO9pQI0qjymiY0/abKeZJ4tsVw=
Bytes: 2832

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> 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.

Available online at :

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1637.pdf

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */