On Mon, 05 Jan 2026 18:20:24 GMT, Charlie Gibbs wrote:

Let me guess: so companies can sell you a new compiler every year,
plus courses in how to use the new shit.

Nobody pays money for compilers any more. All the important tools are open-source now.

The days of trying to monetize development tools, like in the 1980s
and 1990s, are long past.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Niklas Karlsson wrote this post by blinking in Morse code:

On 2026-01-05, rbowman <bowman@montana.com> wrote:

You can really blame Microsoft for creating MFC; they had to wrap their C >> API in something. You can blame them for DDE/OLE/COM, the ATl, and
adopting Hungarian notation.

(I assume you meant "can't really blame" at the beginning there?)

Time to dip into the quotes file again:

Hungarian Notation is the tactical nuclear weapon of source code
obfuscation techniques.
-- Roedy Green

Agreed. The only warts I use are:

m_ A class member. But I often make an accessor function
without the "m_"
sm_ A static class member.
c_ A constant, not in a class..

Of course, there's no way in hell to get programmer's to agree on
coding conventions.

That's why I'm happy to work on my own now.

--
... an anecdote from IBM's Yorktown Heights Research Center. When a
programmer used his new computer terminal, all was fine when he was sitting down, but he couldn't log in to the system when he was standing up. That behavior was 100 percent repeatable: he could always log in when sitting and never when standing.

Most of us just sit back and marvel at such a story; how could that terminal know whether the poor guy was sitting or standing? Good debuggers, though, know that there has to be a reason. Electrical theories are the easiest to hypothesize: was there a loose wire under the carpet, or problems with static electricity? But electrical problems are rarely consistently reproducible.
An alert IBMer finally noticed that the problem was in the terminal's keyboard: the tops of two keys were switched. When the programmer was seated he was a touch typist and the problem went unnoticed, but when he stood he was led astray by hunting and pecking.
-- "Programming Pearls" column, by Jon

On 1/5/26 13:20, Charlie Gibbs wrote:

On 2026-01-05, The Natural Philosopher <tnp@invalid.invalid> wrote:

On 05/01/2026 17:48, rbowman wrote:

The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted with >>> "Hell yeah!" rather than "What CS PhD dreamed this crap up?"

Spot on.

C is enough to do the job and simple to learn. Why complicate shit?

Let me guess: so companies can sell you a new compiler every year,
plus courses in how to use the new shit.

Cynical ... but perhaps partially true.

Mostly, it's that everybody thinks they
have the Better Idea, the Better Approach.

There really isn't anything you can't do
with 'C'. However 'C' is kind of CLUNKY
sometimes - so people find ways to hide
that, write something more 'elegant' in
the process. Python is ACTUALLY 'C' ...
but many of the clunky and/or long bits
have been much streamlined.

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.

But it CAN be much more friendly and/or
tuned to a particular area of interest
or preferred programming style.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/5/26 22:25, Chris Ahlstrom wrote:

Niklas Karlsson wrote this post by blinking in Morse code:

On 2026-01-05, rbowman <bowman@montana.com> wrote:

You can really blame Microsoft for creating MFC; they had to wrap their C >>> API in something. You can blame them for DDE/OLE/COM, the ATl, and
adopting Hungarian notation.

(I assume you meant "can't really blame" at the beginning there?)

Time to dip into the quotes file again:

Hungarian Notation is the tactical nuclear weapon of source code
obfuscation techniques.
-- Roedy Green

Agreed. The only warts I use are:

m_ A class member. But I often make an accessor function
without the "m_"
sm_ A static class member.
c_ A constant, not in a class..

I thought that all stopped 15-20 years ago when IDEs introduced auto colouring.



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/5/26 11:50, Chris Ahlstrom wrote:

Lawrence D?Oliveiro wrote this post by blinking in Morse code:

On Sun, 04 Jan 2026 19:41:11 GMT, Charlie Gibbs wrote:

Does C# qualify as a Microsoft proprietary language? Or are there
implementations on OSes other than Windows (and compilers, either
open source or available from other vendors)?

The only implementation I?m aware of is Microsoft?s one built on top
of Dotnet.

Dotnet itself is supposedly open-source and portable to some degree
now. There are reports of it running on Linux.

<https://learn.microsoft.com/en-us/dotnet/core/install/linux>

Install .NET on Linux

Also:

<https://github.com/mono/mono>

C# is a lovely language, but isn't different enough from Java to make it worthwhile doing something with much less online support when using Linux.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Pancho wrote this post by blinking in Morse code:

On 1/5/26 22:25, Chris Ahlstrom wrote:

Niklas Karlsson wrote this post by blinking in Morse code:

On 2026-01-05, rbowman <bowman@montana.com> wrote:

You can really blame Microsoft for creating MFC; they had to wrap their C >>>> API in something. You can blame them for DDE/OLE/COM, the ATl, and
adopting Hungarian notation.

(I assume you meant "can't really blame" at the beginning there?)

Time to dip into the quotes file again:

Hungarian Notation is the tactical nuclear weapon of source code
obfuscation techniques.
-- Roedy Green

Agreed. The only warts I use are:

m_ A class member. But I often make an accessor function
without the "m_"
sm_ A static class member.
c_ A constant, not in a class..

I thought that all stopped 15-20 years ago when IDEs introduced auto colouring.

I don't use an IDE. Just vim and build scripts like make and
Meson.

Vim has syntax highlighting, and I've added a ton of my own key
words to ~/.vim/after/syntax.

What IDEs auto-color tokens based on whether they are class
members or not?

--
Marriage is the sole cause of divorce.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-05 19:09, The Natural Philosopher wrote:

On 05/01/2026 17:48, rbowman wrote:

The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted
with
"Hell yeah!" rather than "What CS PhD dreamed this crap up?"

Spot on.

C is enough to do the job and simple to learn. Why complicate shit?

My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a proper language would catch.

That was around 1991.

He knew. He participated in some study tasked by the Canadian government
to study C compilers, but he could not talk about what they wrote.

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/6/26 05:36, Carlos E.R. wrote:

On 2026-01-05 19:09, The Natural Philosopher wrote:

On 05/01/2026 17:48, rbowman wrote:

The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted
with
"Hell yeah!" rather than "What CS PhD dreamed this crap up?"

Spot on.

C is enough to do the job and simple to learn. Why complicate shit?

My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a proper language would catch.

That was around 1991.

He knew. He participated in some study tasked by the Canadian government
to study C compilers, but he could not talk about what they wrote.

This was always my feeling. C is great as a low-level language, but
extending its use cases caused a lot of problems. Also, extensions has
been added to K&R C (some necessary, but many not) that has complexified
the syntax into unreadability. PL/I was designed with all the features
that were later added to C, so the end result is cleaner.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

[Note Followup-To]

On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:

My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a proper language would catch.

That was around 1991.

He knew. He participated in some study tasked by the Canadian government
to study C compilers, but he could not talk about what they wrote.

I agree that C does the job reasonably well, and it is simple.
And so, like most other geeks my age, I write with the tools I
have used in forever, rather than spending my time learning new
tools. For me, those tools are:
- C
- vim
- perl
- HTML (1.0)
And yes, it is like using a vintage Jeep for a daily driver.

The most egregious problem with old C is string handling.
A useful "string" type would have
- a maximum length, using hardware (exception) bounds checking.
to be useful, this would mean a length field in front of
the char[]
- ideally, an option for the length to be dynamic, reallocating
the memory as needed. Would require the base representation
to be a pointer to the struct. Would be a lot of "under the
hood" stuff, and probably inefficient.

** and now a digression **

The VAX architecture with its descriptors and universal calling
sequences was a great foundation, but K&R C did not fit, because
a byte-addressed memory was assumed, and you could not put the
descriptors in the middle of a struct and still have the code be
portable. So for anything with networking, which relied on being
able to import the Berkeley networking code, all the descriptor
stuff was of no use. For a lot of other code, it was amazingly
good. The unified calling structure and the way an exception
could be unwound up multiple levels of stack and simply be
converted to an error return code at the top level of a layered
library was pretty miraculous. And the instruction set was
very intuitive. I wrote a lot of kernel code in Macro-32,
and it was almost as fast as writing C.

The people in comp.arch look down of how inefficient the VAX
was, and how the microcode tricks used to make fast CPUs with
pipelining and out-of-order execution would not work for a VAX.
I think that is just an example of how the arch of history often
looks inevitable in hindsight.
--
Lars Poulsen - an old geek in Santa Barbara, California

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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() ?

</interjection>

There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.

There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.

--
Paul's Law:
You can't fall off the floor.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

Of course, one can use `setjmp` and `longjmp` to build an ersatz
exception system, but only as a part. One can also use them to
build green threads, but they are not in themselves "threads".

- Dan C.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/01/2026 12:36, Carlos E.R. wrote:

On 2026-01-05 19:09, The Natural Philosopher wrote:

On 05/01/2026 17:48, rbowman wrote:

The C changes over the years like being able to declare variables where
they are first used and single line comments were something I greeted
with
"Hell yeah!" rather than "What CS PhD dreamed this crap up?"

Spot on.

C is enough to do the job and simple to learn. Why complicate shit?

My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a proper language would catch.

That was around 1991.

He knew.

How to make mistakes, but not to program defensively

You don't treat a chainsaw like a palette knife for cake icing.

He participated in some study tasked by the Canadian government
to study C compilers, but he could not talk about what they wrote.

Mostly bollocks then...

--
?Puritanism: The haunting fear that someone, somewhere, may be happy.?

H.L. Mencken, A Mencken Chrestomathy


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/01/2026 16:12, Chris Ahlstrom 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() ?

Exactly. The problem with making high level 'features' in a language is
people then don't see how they actually work.

One of the worst features of C libs is malloc() and free() where the underlying mechanism is opaque.

auto allocation and garbage collection is even worse.

Also operator overloading and weak typing.

You simply do not know where you are.

It's all fearfully clever ins a smart alec sort of way but it makes for
a lot of problems downstream...

--
I was brought up to believe that you should never give offence if you
can avoid it; the new culture tells us you should always take offence if
you can. There are now experts in the art of taking offence, indeed
whole academic subjects, such as 'gender studies', devoted to it.

Sir Roger Scruton


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <10jjgju$5l5$3@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> wrote:

On 06/01/2026 16:12, Chris Ahlstrom 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() ?

Exactly. The problem with making high level 'features' in a language is >people then don't see how they actually work.

What an odd take.

The point of programming is to write programs. The point of
maintenance is to make sure those programs continue working over
time as technology and environments change. C (and for that
matter Unix) were invented to make writing and maintaining
programs easier than the techniques that had been used up to
that point, not to elucidate the implementation. This idea of
C as some kind of glorified "high-level" assembler hasn't been
true since we started to see optimizing compilers in the 1970s.

One of the worst features of C libs is malloc() and free() where the >underlying mechanism is opaque.

...because it is utterly irrelevant to 99.99% of programs.

If you want to see how it works under the hood, go look up the
system interface. But if done properly, that's independent of
the user application language. Or, if you can, read the library
source if you want to see how `malloc` is implemented: this is
one of the benefits of open source software.

The claim that `malloc` is bad because it hides the details of
memory management is just silly. stdio hides the details of
blocks, buffer caches, bus acceses, DMA, asynchronous descriptor
queues, IO devices and their access mechanisms, and so on, from
programmers. Because, again, it's totally irrelevant for _most_
programs. Is that similarly bad?

auto allocation and garbage collection is even worse.

Also operator overloading and weak typing.

You simply do not know where you are.

Most programmers don't know that stuff anyway. Most have no
idea how their program is loaded into memory or starts running,
how the platform is initialized, the implementation of the sorts
of abstractions that the OS provides, and so on.

It's all fearfully clever ins a smart alec sort of way but it makes for
a lot of problems downstream...

Nonsense.

- Dan C.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.

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).

//
// Now we execute the instruction.
//
switch (setjmp(p_fault)) {
case 0:
//
// If a fault was thrown (longjmp) during operand
// fetch, p_fetch_fault will be true, the state of the
// p_operands[] array will be indeterminate and we don't
// want to execute the instruction. Unless it is a non-taken
// branch, that is, which is allowed to have e.g. undigits in
// the branch address. Blech. This means the branch ops
// must test the p_operands[0] value before accessing it.
//
if (branch || !p_fetch_fault) {
failed = (this->*opp->op_insn)(opp);
}

if (branch) {
if (!p_taken) {
if (p_fetch_fault) {
p_fetch_fault = false;
p_rd.clear();
}
}
}

if (p_fetch_fault) {
char buf[10];
char buf1[20];

p_rd.format(buf1, sizeof(buf1));
p_logger->log("[%01lu/%04lu] Fetch Fault %s at @%s:%06llu\n",
p_procnum, p_curtasknum, buf1,
p_active_env.print(buf, sizeof(buf)), p_ip);
failed = true;
}
break;
case 1:
failed = false;
//
// Generic error. Assume failed; there's most likely a non-zero
// processor Result Descriptor (p_rd) at this point.
//
break;
case 2:
//
// Hard memory area fault. We've already done the hardware call
// procedure (since we knew the mast number), so the processor R/D
// has already been stored and cleared. Fake success for the op
// to handle the fault.
//
failed = false;
break;
case 3:
//
// Maintenance processor requested a stop while we were idle on a
// IDL or BRV instruction. Just replay the instruction.
//
p_logger->log("[%1.1lu/%4.4lu] Maintenance Processor Stop\n",
p_procnum, p_curtasknum);
p_ip = p_origip;
return false;
}

inline void
c_processor::instruction_error(instruction_error_t extension)
{
p_rd.instruction_error(extension);
//p_logger->backtrace();
longjmp(p_fault, 1);
}

inline void
c_processor::address_error(address_error_t extension)
{
p_rd.address_error(extension);
//p_logger->backtrace();
longjmp(p_fault, 1);
}

/**
* Raise an instruction_timeout. Caused by infinite (or too long) recursion in
* indirect field lengths, indirect addresses and search list instructions.
*/
inline void
c_processor::instruction_timeout(void)
{
p_rd.instruction_timeout();
longjmp(p_fault, 1);
}

inline void
c_processor::stack_overflow(void)
{
p_rd.stack_overflow();
longjmp(p_fault, 1);
}

inline void
c_processor::invalid_arithmetic_data(void)
{
p_rd.invalid_arithmetic_data();
//p_logger->backtrace();
longjmp(p_fault, 1);
}

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-06, Lars Poulsen <lars@beagle-ears.com> wrote:

On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:

My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a
proper language would catch.

That was around 1991.

He knew. He participated in some study tasked by the Canadian government
to study C compilers, but he could not talk about what they wrote.

What language(s) did he suggest instead?

I agree that C does the job reasonably well, and it is simple.
And so, like most other geeks my age, I write with the tools I
have used in forever, rather than spending my time learning new
tools. For me, those tools are:
- C
- vim
- perl
- HTML (1.0)
And yes, it is like using a vintage Jeep for a daily driver.

You mean pulling those fancy cars out of a ditch? It's fun...

The most egregious problem with old C is string handling.
A useful "string" type would have
- a maximum length, using hardware (exception) bounds checking.
to be useful, this would mean a length field in front of
the char[]
- ideally, an option for the length to be dynamic, reallocating
the memory as needed. Would require the base representation
to be a pointer to the struct. Would be a lot of "under the
hood" stuff, and probably inefficient.

Inspired by readline(), I've written my own replacements for
strcpy() and strcat() that do much the same thing.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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?

- Dan C.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 6 Jan 2026 07:55:03 -0700, Peter Flass wrote:

PL/I was designed with all the features that were later added to C,
so the end result is cleaner.

PL/I had its own surprises, possibly like C++, maybe even worse.
Like automatic type conversions that produce entirely unexpected
results.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/6/26 07:16, Waldek Hebisch wrote:

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. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.

There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.

You give it a file in whatever lang, it produces
a file in 'C' and compiles that. So, I'll basically
stick with my 'translator' def. And if 'C' does not
'natively support' something you can FAKE it with code,
not really anything you CAN'T do with 'C'.

By 'compiler' I mean "source in -> (agitating sounds) ->
binary executable out.

I think there are still a few FORTRAN compilers out
there for Linux, maybe COBOL too. There's at least
one forth IDE/compiler. Digital Mars makes 'C' and
'D' compilers. GCC is not the alpha and omega
of software development.

But it CAN be much more friendly and/or
tuned to a particular area of interest
or preferred programming style.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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. 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


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

rbowman <bowman@montana.com> writes:

On Tue, 06 Jan 2026 18:57:04 GMT, Charlie Gibbs wrote:

Inspired by readline(), I've written my own replacements for strcpy()
and strcat() that do much the same thing.

To quote from the strcat man page "Read about Shlemiel the painter.". >stpcpy() was a late arrival and I never used it. I do use a similar >construct

char buf[1024];
char* ptr = buf;

ptr += sprintf(ptr, "%s", "some stuff");
ptr += sprintf(ptr, "%s", " some more stuff");

I would suggest using snprintf instead of sprintf
to prevent accesses beyond (buf + 1024). A bit
more complicated if you want to know that the
result was truncated, since you need to adjust the
remaining length based on the return value from
the prior snprintf, as well as checking for
overflow.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

scott@slp53.sl.home (Scott Lurndal) writes:

rbowman <bowman@montana.com> writes:

On Tue, 06 Jan 2026 18:57:04 GMT, Charlie Gibbs wrote:

Inspired by readline(), I've written my own replacements for strcpy()
and strcat() that do much the same thing.

To quote from the strcat man page "Read about Shlemiel the painter.". >>stpcpy() was a late arrival and I never used it. I do use a similar >>construct

char buf[1024];
char* ptr = buf;

ptr += sprintf(ptr, "%s", "some stuff");
ptr += sprintf(ptr, "%s", " some more stuff");

I would suggest using snprintf instead of sprintf
to prevent accesses beyond (buf + 1024). A bit
more complicated if you want to know that the
result was truncated, since you need to adjust the
remaining length based on the return value from
the prior snprintf, as well as checking for
overflow.

This is calling out for a wrapping up in a function or two that can do
the book-keeping automatically (and use an expandable buffer, if the use
case demands).

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

antispam@fricas.org (Waldek Hebisch) writes:

In alt.folklore.computers c186282 <c186282@nnada.net> wrote:

On 1/6/26 07:16, Waldek Hebisch wrote:

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. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.

There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.

You give it a file in whatever lang, it produces
a file in 'C' and compiles that.

No, if you looked at what compilers in gcc are doing you
will see that there are no intemediate C file. There
is intermediate assembler, but between source file and
assembler each compiler work independently

AFAIK you can remove C compiler binary and other compilers in
gcc will still work.

So, I'll basically
stick with my 'translator' def. And if 'C' does not
'natively support' something you can FAKE it with code,
not really anything you CAN'T do with 'C'.

A I wrote, you can use "via C" translators, but results are
not so good as with dedicated compilers, that is why gcc
contains separate compilers.

By 'compiler' I mean "source in -> (agitating sounds) ->
binary executable out.

By that definition gcc does _not_ contain a C compiler:
gcc generates assembly and then assembler and linker produce
final executable.

Actually, the C front-end will translate C into an
intermediate tree representation. That tree is passed to a
target architecture specific back-end that generates
assembler and the gcc driver calls gas(1) (or other
compatible assembler) to convert the assembler language
into a binary object file. The driver then passes the
object file (and other command line arguments) to the
linker utility to generate the executable.

The back-ends only look at the common intermediate
representation and have no visibility into the actual
source language.



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/6/26 18:10, Waldek Hebisch wrote:

In alt.folklore.computers c186282 <c186282@nnada.net> wrote:

On 1/6/26 07:16, Waldek Hebisch wrote:

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. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.

There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.

You give it a file in whatever lang, it produces
a file in 'C' and compiles that.

No, if you looked at what compilers in gcc are doing you
will see that there are no intemediate C file. There
is intermediate assembler, but between source file and
assembler each compiler work independently

AFAIK you can remove C compiler binary and other compilers in
gcc will still work.

So, I'll basically
stick with my 'translator' def. And if 'C' does not
'natively support' something you can FAKE it with code,
not really anything you CAN'T do with 'C'.

A I wrote, you can use "via C" translators, but results are
not so good as with dedicated compilers, that is why gcc
contains separate compilers.

By 'compiler' I mean "source in -> (agitating sounds) ->
binary executable out.

By that definition gcc does _not_ contain a C compiler:
gcc generates assembly and then assembler and linker produce
final executable. Things are more complicated when you use
LTO, because "linker" in this case actially is doing large part
of compiler work and optimized code before producing final
executable. But non-LTO compilation works via assembly.

Clearly the GCC collection is More Complicated
than I thought.

But I'm still not sure I'll call them 'compilers'
in the older sense of the word. Some intermediate
term is required.

I think there are still a few FORTRAN compilers out
there for Linux, maybe COBOL too. There's at least
one forth IDE/compiler. Digital Mars makes 'C' and
'D' compilers. GCC is not the alpha and omega
of software development.

But it CAN be much more friendly and/or
tuned to a particular area of interest
or preferred programming style.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-06, Waldek Hebisch <antispam@fricas.org> wrote:

In alt.folklore.computers c186282 <c186282@nnada.net> wrote:

On 1/6/26 07:16, Waldek Hebisch wrote:

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. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.

There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.

You give it a file in whatever lang, it produces
a file in 'C' and compiles that.

No, if you looked at what compilers in gcc are doing you
will see that there are no intemediate C file. There
is intermediate assembler, but between source file and
assembler each compiler work independently

Still, Bjarne Stroustrup's first implementation of C++
was a program called cfront, which translated C++ to C.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-07, rbowman <bowman@montana.com> wrote:

On Tue, 06 Jan 2026 22:54:26 +0000, Richard Kettlewell wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

rbowman <bowman@montana.com> writes:

On Tue, 06 Jan 2026 18:57:04 GMT, Charlie Gibbs wrote:

Inspired by readline(), I've written my own replacements for strcpy() >>>>> and strcat() that do much the same thing.

To quote from the strcat man page "Read about Shlemiel the painter.".
stpcpy() was a late arrival and I never used it. I do use a similar
construct

char buf[1024];
char* ptr = buf;

ptr += sprintf(ptr, "%s", "some stuff");
ptr += sprintf(ptr, "%s", " some more stuff");

I would suggest using snprintf instead of sprintf to prevent accesses
beyond (buf + 1024). A bit more complicated if you want to know that
the result was truncated, since you need to adjust the remaining length
based on the return value from the prior snprintf, as well as checking
for overflow.

This is calling out for a wrapping up in a function or two that can do
the book-keeping automatically (and use an expandable buffer, if the use
case demands).

Ah, mission creep...

Yes, I haven't been able to justify doing an equivalent for sprintf() yet.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <ZN-dnY--SfIc4MD0nZ2dnZfqnPednZ2d@giganews.com>,
c186282 <c186282@nnada.net> wrote:

On 1/6/26 07:16, Waldek Hebisch wrote:

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. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.

There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.

You give it a file in whatever lang, it produces
a file in 'C' and compiles that.

No. That's not how it works. This is factually wrong.

- Dan C.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

rbowman <bowman@montana.com> writes:

On Tue, 6 Jan 2026 08:03:13 +0000, Pancho wrote:

C# is a lovely language, but isn't different enough from Java to make it
worthwhile doing something with much less online support when using
Linux.

C# is what Java should have been, I had hopes for Java in the late '90s
that were dashed when it became bloated and slow.

I find this remark interesting. C# is actively acquiring all kinds of programming paradigms / language constructs making it a "large" language,
and imposing the "burden" of continuously having to think "should I use
this construct, or should I use that construct" upon the programmer.

Apart from that, MS continuously changes the .NET libraries, yielding a permanent present "technical debt".

Also, in C# I have to actively program for efficiency, while in Java the JVM takes more or less care of that.

I always find Java very productive. Conservative, but productive. Simply because, well, there is less choice in language constructs and the API's
are more stable. And because Maven is much more sophisticated than NuGet :)

Don't get me wrong, I appreciate C# as a language, but I think quite a lot
of software would be better off (read: could be constructed faster) if not written written in C# / .NET but in Java and it's ecosystem.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-06 19:57, Charlie Gibbs wrote:

On 2026-01-06, Lars Poulsen <lars@beagle-ears.com> wrote:

On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:

My C teacher said it was a mistake to use C as an all purpose language,
like for userland applications. Using C is the cause of many bugs that a >>> proper language would catch.

That was around 1991.

He knew. He participated in some study tasked by the Canadian government >>> to study C compilers, but he could not talk about what they wrote.

What language(s) did he suggest instead?

I don't remember if he did. Maybe he told samples, but I think he mostly
told us of quirks of the language, things that were errors, but that the compiler did not signal, so that we being aware we would write correct C
code.

It is possible that current C compilers signal many more problems that
back then, but not runtime errors.

I would have to seek my hand notes.

Mostly accessing variables beyond the end of it. Arrays or strings were
the most blatant example.

...
--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

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.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/6/26 14:24, c186282 wrote:

On 1/6/26 07:16, Waldek Hebisch wrote:

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.ÿ C++ (and some other languages)
have exceptions, C do not have them.ÿ There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo.ÿ During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.

There were/are compilers that work by translating to C.ÿ But
this has limitations: generated code typically is worse because
language specific information is lost in translation.ÿ Error
reporting is worse because translator is not doing as many
analyzes as gcc do.ÿ For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.

ÿ You give it a file in whatever lang, it produces
ÿ a file in 'C' and compiles that. So, I'll basically
ÿ stick with my 'translator' def. And if 'C' does not
ÿ 'natively support' something you can FAKE it with code,
ÿ not really anything you CAN'T do with 'C'.

ÿ By 'compiler' I mean "source in -> (agitating sounds) ->
ÿ binary executable out.

ÿ I think there are still a few FORTRAN compilers out
ÿ there for Linux, maybe COBOL too. There's at least
ÿ one forth IDE/compiler. Digital Mars makes 'C' and
ÿ 'D' compilers. GCC is not the alpha and omega
ÿ of software development.

ÿÿ But it CAN be much more friendly and/or
ÿÿ tuned to a particular area of interest
ÿÿ or preferred programming style.

Iron Spring PL/I compiles directly to binary. It can produce assembler
output, but only as a by-product of generating the object file. I have occasionally thought of trying to make it another front-end for GCC. As
I understand it, GCC compiles to an intermediate language, not to C.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <10jlqu8$mvh2$3@dont-email.me>,
Peter Flass <Peter@Iron-Spring.com> wrote:

On 1/6/26 14:24, c186282 wrote:

On 1/6/26 07:16, Waldek Hebisch wrote:

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.ÿ C++ (and some other languages)
have exceptions, C do not have them.ÿ There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo.ÿ During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.

There were/are compilers that work by translating to C.ÿ But
this has limitations: generated code typically is worse because
language specific information is lost in translation.ÿ Error
reporting is worse because translator is not doing as many
analyzes as gcc do.ÿ For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.

ÿ You give it a file in whatever lang, it produces
ÿ a file in 'C' and compiles that. So, I'll basically
ÿ stick with my 'translator' def. And if 'C' does not
ÿ 'natively support' something you can FAKE it with code,
ÿ not really anything you CAN'T do with 'C'.

ÿ By 'compiler' I mean "source in -> (agitating sounds) ->
ÿ binary executable out.

ÿ I think there are still a few FORTRAN compilers out
ÿ there for Linux, maybe COBOL too. There's at least
ÿ one forth IDE/compiler. Digital Mars makes 'C' and
ÿ 'D' compilers. GCC is not the alpha and omega
ÿ of software development.

ÿÿ But it CAN be much more friendly and/or
ÿÿ tuned to a particular area of interest
ÿÿ or preferred programming style.

Iron Spring PL/I compiles directly to binary. It can produce assembler >output, but only as a by-product of generating the object file. I have >occasionally thought of trying to make it another front-end for GCC. As
I understand it, GCC compiles to an intermediate language, not to C.

GCC's frontends, like those of most modern compilers, generate
an intermediate representation (that is, indeed, not C). That,
in turn, is optimized and presented to a backend, that uses the
IR to generate machine code for a target instruction set. In
this way, any of the languages that the GCC front-end recognize
can be targetted to any of the architectures its backend
supports.

Whether that machine code is in binary object code or textual
assembly code hardly matters; the hard work of the compiler is
in the transation from source to machine code.

Separate assembly and link stages are hidden by the compiler
driver program (e.g., the `gcc` program itself), but don't
change the fact that, yes, Virginia, GCC is actually a compiler.

These bizarre definitional assertions about what makes something
a "compiler" or not seem to be mostly put forth by people who
have never heard of the concept of "separate compilation" or
"libraries", let alone touched the innards of a compiler. In
particular, this idea that everything must be implemented in a
single program or it's not a "true" compiler is rooted firmly in
ignorance.

- Dan C.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

On 2026-01-06, Waldek Hebisch <antispam@fricas.org> wrote:

In alt.folklore.computers c186282 <c186282@nnada.net> wrote:

On 1/6/26 07:16, Waldek Hebisch wrote:

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. C++ (and some other languages)
have exceptions, C do not have them. There are several
smaller things, for example Ada or Pascal modulo is different
that C/Fortran modulo. During optimization passes gcc
keeps such information, to allow better optimization and
error reporting.

There were/are compilers that work by translating to C. But
this has limitations: generated code typically is worse because
language specific information is lost in translation. Error
reporting is worse because translator is not doing as many
analyzes as gcc do. For those reasons compilers in gcc
generate common representation which contains sum of features
of all supported languages and not C.

You give it a file in whatever lang, it produces
a file in 'C' and compiles that.

No, if you looked at what compilers in gcc are doing you
will see that there are no intemediate C file. There
is intermediate assembler, but between source file and
assembler each compiler work independently

Still, Bjarne Stroustrup's first implementation of C++
was a program called cfront, which translated C++ to C.

Rather ugly C, at that. I had to fix a bug in PCC[*] caused
by the excessive use of the comma operator in the cfront
generated C code.

[*] Exhausted the temp registers generating the expression. Had
to add sethi-ullman temp register allocation algorithm to PCC
(generating code for the Motorola 88100) to handle the spills.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

cross@spitfire.i.gajendra.net (Dan Cross) writes:

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.

For that, only -fno-exceptions is necessary. The others were
left over - I had adapted the make files from a hypervisor project
(where the first three flags were necessary).

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/7/26 08:13, Dan Cross wrote:

These bizarre definitional assertions about what makes something
a "compiler" or not seem to be mostly put forth by people who
have never heard of the concept of "separate compilation" or
"libraries", let alone touched the innards of a compiler. In
particular, this idea that everything must be implemented in a
single program or it's not a "true" compiler is rooted firmly in
ignorance.

I think compilers have generated intermediate code since the first
FORTRAN compiler. The only distinction is one vs. multiple programs. Wth
a variety of both front- and back-ends GCC has good reason to separate
them. On the other hand, a compiler that uses another compiled language
as intermediate code is a strange beast, probably better called a
translator.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 7 Jan 2026 12:20:54 -0700
Peter Flass <Peter@Iron-Spring.com> wrote:

On the other hand, a compiler that uses another compiled language
as intermediate code is a strange beast, probably better called a translator.

It's historically a pretty common thing to do when getting a new
language off the ground, whilst getting the kinks out and before one
has the time to write a dedicated compiler. In addition to C++, IIRC Objective-C also started out with a translator-compiler.

It also allows the same language to be deployed in multiple different environments with minimal effort - Nim, f'rexample, compiles to Java-
script as well as C-family and LLVM intermediate backends, so it can be
used for web development.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 07/01/2026 15:13, Dan Cross wrote:

These bizarre definitional assertions about what makes something
a "compiler" or not seem to be mostly put forth by people who
have never heard of the concept of "separate compilation" or
"libraries", let alone touched the innards of a compiler. In
particular, this idea that everything must be implemented in a
single program or it's not a "true" compiler is rooted firmly in
ignorance.

<applause>

--
Climate Change: Socialism wearing a lab coat.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 7 Jan 2026 12:20:54 -0700, Peter Flass wrote:

On the other hand, a compiler that uses another compiled language as intermediate code is a strange beast, probably better called a
translator.

There is a term for that: ?transpiler?.

But really, the distinction is arbitrary.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/01/2026 23:10, Waldek Hebisch wrote:

No, if you looked at what compilers in gcc are doing you
will see that there are no intemediate C file. There
is intermediate assembler, but between source file and
assembler each compiler work independently

I assumed so, but its nice to have it confirmed...

AFAIK you can remove C compiler binary and other compilers in
gcc will still work.

That is news to me, but it makes sense.

So, I'll basically
stick with my 'translator' def. And if 'C' does not
'natively support' something you can FAKE it with code,
not really anything you CAN'T do with 'C'.

A I wrote, you can use "via C" translators, but results are
not so good as with dedicated compilers, that is why gcc
contains separate compilers.

By 'compiler' I mean "source in -> (agitating sounds) ->
binary executable out.

By that definition gcc does_not_ contain a C compiler:
gcc generates assembly and then assembler and linker produce
final executable. Things are more complicated when you use
LTO, because "linker" in this case actially is doing large part
of compiler work and optimized code before producing final
executable. But non-LTO compilation works via assembly.

And thank heavens it does. Sometimes examining the assembler is
necessary, though thankfully fairly rarely these days.



--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1/7/26 17:49, rbowman wrote:

On Wed, 7 Jan 2026 13:30:14 +0100, Carlos E.R. wrote:

On 2026-01-06 19:57, Charlie Gibbs wrote:

On 2026-01-06, Lars Poulsen <lars@beagle-ears.com> wrote:

On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:

My C teacher said it was a mistake to use C as an all purpose
language, like for userland applications. Using C is the cause of
many bugs that a proper language would catch.

That was around 1991.

He knew. He participated in some study tasked by the Canadian
government to study C compilers, but he could not talk about what
they wrote.

What language(s) did he suggest instead?

I don't remember if he did. Maybe he told samples, but I think he mostly
told us of quirks of the language, things that were errors, but that the
compiler did not signal, so that we being aware we would write correct C
code.

It is possible that current C compilers signal many more problems that
back then, but not runtime errors.

gcc has become pickier. That isn't always a welcome thing when working
with legacy code and requires a search of the compiler options to get it
to shut up about such horrible heresies as assuming a function returns an int.

Yea ... noticed this trend.

I *suppose* it's "for the best" ... however .....

Admit it ... people OFTEN write HORRIBLE code with
all sorts of 'assumptions' and security-vulnerable
stuff in there. It's probably why M$ has some major
security prob listed every week .....


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 07/01/2026 22:49, rbowman wrote:

On Wed, 7 Jan 2026 13:30:14 +0100, Carlos E.R. wrote:

On 2026-01-06 19:57, Charlie Gibbs wrote:

On 2026-01-06, Lars Poulsen <lars@beagle-ears.com> wrote:

On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:

My C teacher said it was a mistake to use C as an all purpose
language, like for userland applications. Using C is the cause of
many bugs that a proper language would catch.

That was around 1991.

He knew. He participated in some study tasked by the Canadian
government to study C compilers, but he could not talk about what
they wrote.

What language(s) did he suggest instead?

I don't remember if he did. Maybe he told samples, but I think he mostly
told us of quirks of the language, things that were errors, but that the
compiler did not signal, so that we being aware we would write correct C
code.

It is possible that current C compilers signal many more problems that
back then, but not runtime errors.

gcc has become pickier. That isn't always a welcome thing when working
with legacy code and requires a search of the compiler options to get it
to shut up about such horrible heresies as assuming a function returns an int.

Actually I welcome that. at leats 10% of the time the compiler finds a
bug that way, and the other 90% i upgrade the source to be more explicit...





--
The theory of Communism may be summed up in one sentence: Abolish all
private property.

Karl Marx



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-08, The Natural Philosopher <tnp@invalid.invalid> wrote:

On 07/01/2026 22:49, rbowman wrote:

On Wed, 7 Jan 2026 13:30:14 +0100, Carlos E.R. wrote:

It is possible that current C compilers signal many more problems that
back then, but not runtime errors.

gcc has become pickier. That isn't always a welcome thing when working
with legacy code and requires a search of the compiler options to get it
to shut up about such horrible heresies as assuming a function returns an
int.

Actually I welcome that. at leats 10% of the time the compiler finds a
bug that way, and the other 90% i upgrade the source to be more explicit...

+1

I re-worked my code over time so that -Wall yields no errors.
And then a new version of gcc comes out which picks even more
nits, and the process repeats. Not being a quick-and-dirty
type, I consider it a win overall.

The one exception is its scrutiny of printf() calls.
That was a step too far, so I added -Wno-format-overflow.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-08, rbowman <bowman@montana.com> wrote:

It was never a good idea but the legacy code often defined a variable in
a .h file. The newer gcc implementations would throw multiple definition errors. Fixing it would have been painful. foo.h that defined int bar;
might be included in several different programs so you would have to hunt down all the uses and then define bar someplace in a .c file.

Great project for the new guy but at the time the newest guy had been
there for 20 years. Adding the compiler flag to the relevant makefiles was easier.

In multi-module programs I define my globals in a .h file as follows:

common.h
--------
#ifdef PRIMARY
#define GLOBAL
#else
#define GLOBAL extern
#endif

foo.h
-----
#include "common.h"
GLOBAL int foo;

foo1.c
------
#define PRIMARY
#include "foo.h"
int main(int argc, char **argv)
{
setfoo();
printf("foo is %d\n", foo);
exit(0);
}

foo2.c
------
#include "foo.h"
void setfoo()
{
foo = 5;
}

It works for me; I like having only one declaration of "foo"
in my source modules.

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In alt.folklore.computers Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

In multi-module programs I define my globals in a .h file as follows:

common.h
--------
#ifdef PRIMARY
#define GLOBAL
#else
#define GLOBAL extern
#endif

foo.h
-----
#include "common.h"
GLOBAL int foo;

foo1.c
------
#define PRIMARY
#include "foo.h"
int main(int argc, char **argv)
{
setfoo();
printf("foo is %d\n", foo);
exit(0);
}

foo2.c
------
#include "foo.h"
void setfoo()
{
foo = 5;
}

It works for me; I like having only one declaration of "foo"
in my source modules.

I used to do that, and I eventually didn't like it. I then switched to declaring all my global variables in one file:

globals.c
--------

int c_maxitems;
char const *c_name = "Blah de blah blah";
int g_foo;

This file will also contain the code to set global variables that I
consider "constant" (the variables that start with "c_"). This allows them
to be set at program start up. Then the include file:

globals.h
---------

extern int const c_maxitems;
extern char const *const c_name;
extern int g_foo;

extern int global_init(int,char *[]);

Note: "globals.c" will never include "gloabls.h". Oh, and the weird const placement? That avoid the that weird C-spiral rule. The way I use "const" these days means it applies to the thing on the right:

char * p; // mutable pointer to mutable char
char const * q; // mutable pointer to constant char
char *const r; // constant pointer to mutable char
char const *const s; // constant pointer to constant char

Recently, I've been writing code with no global variables. It's been a
fun experiment.

-spc (Why yes, I do have a structure that gets passed to every function,
why do you ask?)

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 9 Jan 2026 00:23:45 -0000 (UTC), sean wrote:

Recently, I've been writing code with no global variables. It's been
a fun experiment.

When I started looking at the Blender source code, I came across these
global variables called ?G? and ?C?. They contained context relating
to the currently-open document.

Finding out where they were defined, across over a million lines of
source code, was a fun exercise. I learned somethings about ctags
along the way ...

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

On 2026-01-08, rbowman <bowman@montana.com> wrote:

It was never a good idea but the legacy code often defined a variable in
a .h file. The newer gcc implementations would throw multiple definition
errors. Fixing it would have been painful. foo.h that defined int bar;
might be included in several different programs so you would have to hunt >> down all the uses and then define bar someplace in a .c file.

Great project for the new guy but at the time the newest guy had been
there for 20 years. Adding the compiler flag to the relevant makefiles was >> easier.

In multi-module programs I define my globals in a .h file as follows:

common.h
--------
#ifdef PRIMARY
#define GLOBAL
#else
#define GLOBAL extern
#endif

Canonically speaking, one uses an 'include guard' to ensure that
a header file is only included once.

Typically

common.h
-------
#if !defined(__common_h__)
#define __common_h__

<header file content>

#endif

In modern C/C++ you can also do this with a single line in the header file

#pragma once



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-07 23:49, rbowman wrote:

On Wed, 7 Jan 2026 13:30:14 +0100, Carlos E.R. wrote:

On 2026-01-06 19:57, Charlie Gibbs wrote:

On 2026-01-06, Lars Poulsen <lars@beagle-ears.com> wrote:

On 2026-01-06, Carlos E.R. <robin_listas@es.invalid> wrote:

My C teacher said it was a mistake to use C as an all purpose
language, like for userland applications. Using C is the cause of
many bugs that a proper language would catch.

That was around 1991.

He knew. He participated in some study tasked by the Canadian
government to study C compilers, but he could not talk about what
they wrote.

What language(s) did he suggest instead?

I don't remember if he did. Maybe he told samples, but I think he mostly
told us of quirks of the language, things that were errors, but that the
compiler did not signal, so that we being aware we would write correct C
code.

It is possible that current C compilers signal many more problems that
back then, but not runtime errors.

gcc has become pickier. That isn't always a welcome thing when working
with legacy code and requires a search of the compiler options to get it
to shut up about such horrible heresies as assuming a function returns an int.

If the code were mine, I would correct the code. Even back then, I did
not take the assumption that a function would return an integer :-D

I wrote explicit prototypes in the header file. :-)


If the code is not mine, I would use the compiler options instead.
Unless I got paid to maintain that code, then I would correct the code.

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Mon, 12 Jan 2026 15:44:56 +0100, Carlos E.R. wrote:

If the code were mine, I would correct the code. Even back then, I
did not take the assumption that a function would return an integer
:-D

That?s why they call it ?technical debt?. And yes, like any debt, it
incurs interest -- compound interest, even ...

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Carlos E.R. wrote this post by blinking in Morse code:

On 2026-01-07 23:49, rbowman wrote:

On 2026-01-06 19:57, Charlie Gibbs wrote:

<snip>

It is possible that current C compilers signal many more problems that
back then, but not runtime errors.

Gcc will tag things that could cause a run-time error, such as
parameters that don't match the specifiers in a printf() call.

gcc has become pickier. That isn't always a welcome thing when working
with legacy code and requires a search of the compiler options to get it
to shut up about such horrible heresies as assuming a function returns an
int.

I periodically also build projects using clang. Clang and gcc each
catch some problems that the other does not catch.

If the code were mine, I would correct the code. Even back then, I did
not take the assumption that a function would return an integer :-D

I wrote explicit prototypes in the header file. :-)

If the code is not mine, I would use the compiler options instead.
Unless I got paid to maintain that code, then I would correct the code.

Don't fix what ain't broke, you might break it [1] :-D

[1] I'm speaking from experience.

--
You can observe a lot just by watching. -- Yogi Berra

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)