Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.os.linux.misc,alt.folklore.computers
Subject: Re: Naughty =?UTF-8?Q?C=E2=99=AF?=
Date: Wed, 7 Jan 2026 13:37:52 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <10jlnjg$o9b$1@reader2.panix.com>
References: <CtydnVqzjrtfd5P0nZ2dnZfqn_adnZ2d@giganews.com> <84c7R.819121$PGrb.160843@fx10.iad> <10jjpjq$p56$2@reader2.panix.com> <fzf7R.805815$i%aa.272881@fx12.iad>
Injection-Date: Wed, 7 Jan 2026 13:37:52 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="24875"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Xref: csiph.com comp.os.linux.misc:80674 alt.folklore.computers:233327

In article <fzf7R.805815$i%aa.272881@fx12.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <84c7R.819121$PGrb.160843@fx10.iad>,
>>Scott Lurndal <slp53@pacbell.net> wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>In article <10jjc9s$3uhtk$1@dont-email.me>,
>>>>Chris Ahlstrom  <OFeem1987@teleworm.us> wrote:
>>>>>Waldek Hebisch wrote this post by blinking in Morse code:
>>>>>
>>>>>> In alt.folklore.computers c186282 <c186282@nnada.net> wrote:
>>>>>> <snip> 
>>>>>>>   Hmm ... look at all the GNU 'compilers' -
>>>>>>>   FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,
>>>>>>>   G++, even Algol-68. None are 'compilers'
>>>>>>>   per-se, but to-'C' TRANSLATORS. So, 'C',
>>>>>>>   pretty much All Are One And One Is All.
>>>>>>
>>>>>> No.  Compiler as first stage translate given language to a
>>>>>> common representation.  This representatiton is different
>>>>>> than C.  Ada and GNU Pascal have parametrized types, there
>>>>>> is nothing like that in C.
>>>>>>
>>>>>> <interjection>
>>>>>>
>>>>>> C++ (and some other languages)
>>>>>> have exceptions, C do not have them.
>>>>>
>>>>>What about setjmp()/longjmp() ?
>>>>
>>>>Not at all the same thing.  `setjmp`/`longjmp` are about
>>>>non-local flows of control; exceptions are about non-local
>>>>passing of values.
>>>
>>>However, in many real world situations, [sig]setjump and
>>>[sig]longjmp can be used to emulate exceptions.
>>
>>Yes, I said just that.  :-)
>>
>>>I have a C++ application that models a computer (Burroughs V380
>>>et alia).   The thread that models each processor (cpu) uses
>>>longjmp whenever a condition is encountered that would have
>>>been signaled as a fault on the real cpu.    The processor code
>>>doesn't do dynamic memory allocation;  and the fault code is
>>>stored in the processor class before the longjmp call.
>>>
>>>I once tried replacing setjmp/longjmp with C++ exceptions which
>>>led to a 20% reduction in simulated CPU performance (as measured
>>>by the time to compile a COBOL program).
>>
>>Huh.  Interesting.  I wonder why...possibly to run a bunch of
>>nop destructors?
>
>A large component of the overhead was the code generated in every
>function to handle unwinding during exception processing.

That makes sense; thanks.

>When
>using setjmp/longjmp, I compiled with the following options so
>it wouldn't generate the unwind code:
>
>GXXFLAGS   = -mno-red-zone
>GXXFLAGS  += -fno-strict-aliasing
>GXXFLAGS  += -fno-stack-protector
>GXXFLAGS  += -fno-exceptions
>GXXFLAGS  += -Wall
>GXXFLAGS  += -mtune=native

Most of those seem irrelevant to generating extra code for stack
unwinding.  `setjmp`/`longjmp` are really just pushing and
popping some register state (including the stack pointer) so
presumably it simply skips all of that code by skipping over any
intermediate stack frame frames?

	- Dan C.