On 7/25/22 1:36 AM, Charlie Gibbs wrote:
> On 2022-07-24, 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> FORTRAN is still pretty widely used also, esp in academic
>> and engineering environments, mostly due to the huge volume
>> of proven hard-core math routines which nobody wants to
>> re-write.
>
> Many rivals, with the benefit of hindsight, have crossed
> swords with the old workhorse! Yet FORTRAN gallops on,
> warts and all, more transportable than syphilis, fired
> by a bottomless pit of working subprograms.
> -- Stan Kelly-Bootle: The Devil's DP Dictionary
>

Fully agree ... NOBODY wants to re-invent it - and
those subs are LONG-PROVEN while replacements would
not be able to make such a claim.

People design buildings, bridges, aircraft, nuclear
reactors, with FORTRAN code. Who would RISK doing
so with 'translations' that might have subtle 'pentium
bugs' within ???

Besides, it's not THAT bad of a language - not too
difficult (except for output formatting). Very
straight-up, not many cryptic symbols or such. Not
a zillion brackets or lambda statements. If you can
program a modern BASIC you can program FORTRAN
real quick. I hadn't touched it in like 40 years and
wrote a nice handy library of useful string and numeric
crap I use in almost every program - within 48 lazy hours.

Then I wrote a utility that translates text-based data
records into a couple of other forms you can more easily
import into common databases. Sure, COULD have wrote that
in Python or 'C' or Pascal ... but ....... :-)

The "modern" design where stuff doesn't have to be
in EXACT locations on the "punch card" DOES make it
all much nicer.

On 7/25/22 4:55 PM, Peter Flass wrote:
> 25B.Z959 <25B.Z959@nada.net> wrote:
>> On 7/23/22 6:23 PM, Peter Flass wrote:
>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> On 7/19/22 10:50 PM, Lew Pitcher wrote:
>>>>> On Tue, 19 Jul 2022 22:34:40 -0400, 25B.Z959 wrote:
>>>>>
>>>>>> On 7/19/22 3:48 PM, Lew Pitcher wrote:
>>>>>>> On Tue, 19 Jul 2022 11:58:29 -0700, Peter Flass wrote:
>>>>>>>
>>>>>>>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>>>>>>>> On 19/07/2022 18:48, Peter Flass wrote:
>>>>>>>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>>>> [snip]
>>>>>>>>>>> Amazing how many institutions STILL run COBOL apps writ
>>>>>>>>>>> during the 60s by the guys with skinny ties. They work
>>>>>>>>>>> very well, they're too expensive to re-do, so ....
>>>>>>>>>>>
>>>>>>>>>>> There's probably a COBOL->C++ or JAVA translator out
>>>>>>>>>>> there somewhere ... but money's so tight these days
>>>>>>>>>>> and so many of those legacy apps are so super-critical
>>>>>>>>>>> that they just can't/won't.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Maybe these are better than translators I have seen, but old ones produced
>>>>>>>>>> unreadable code, and they might well miss some litte tricks that the old
>>>>>>>>>> guys put in, and so leave time-bombs in the translated program. Much more
>>>>>>>>>> expensive, but a lot better, is to extract the specs from the existing
>>>>>>>>>> code, and there are re-engineering programs that can probably do a lot of
>>>>>>>>>> that work, and then rewrite in the new language using programmers skilled
>>>>>>>>>> in that language.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> TBH you cant do many tricks in COBOL and the whole thrust of the bloody
>>>>>>>>> language is 'do it by the book, and write the book as documentation, as
>>>>>>>>> well'
>>>>>>>>>
>>>>>>>>
>>>>>>>> How much would you like to bet? Yes, the language encourages
>>>>>>>> straightforward programming, but I’ve seen things…
>>>>>>>
>>>>>>> A long time ago, I worked on many COBOL applications, including a
>>>>>>> client (PC) / server (MVS) communications application. I've seen
>>>>>>> things that I cannot unsee, coded things that I cannot uncode.
>>>>>>
>>>>>>
>>>>>> Got any of it on a floppy or print-out anywhere ? I'd
>>>>>> love to see how to do client/server only using COBOL.
>>>>>
>>>>> Both client and server used the same COBOL codebase, but with
>>>>> different compilers and operating environments.
>>>>>
>>>>> The client was coded in Microfocus "Visual Object (VISOC)" COBOL
>>>>> and ran on Windows NT 3 and Windows NT 4.1, using a TCP/IP to SNA
>>>>> (terminal communications) connection.
>>>>>
>>>>> The server was coded in IBM COBOL and ran under IMS DC on an MVS
>>>>> system, using an SNA terminal LU as it's communications endpoint.
>>>>>
>>>>> As this was an in-house "inner platform" project (3 tier client/server
>>>>> architecture, circa 1990), I did not keep personal copies of any
>>>>> of the code. Suffice it to say that my first question to the architect,
>>>>> my first day on that project, was "Why COBOL?" The answer was "Because
>>>>> that's what the coders know."
>>>>
>>>>
>>>> Sometimes that IS a factor ... you have to have people who
>>>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>>
>>>
>>> IMNSHO, COBOL. C is a terrible language for those types of language. Things
>>> that are so dimple in COBOL, like moving a character string with blank
>>> fill, or formatting numeric output, requires calling subroutines in C, and
>>> lack of length checking on string moves is a recipe for disaster.
>>>
>>> I have used both languages quite a bit, perhaps COBOL more, years ago, but
>>> neither is my preferred language, so I have no dog in this fight.
>>
>>
>> Sorry, I like 'C' - and have writ little functions, MY way,
>> to do a lot of the things you were talking about.
>>
>> Only ASM gives you more control - and I've done my share of
>> that over the years too.
>>
>>>
>>>>
>>>> Mostly I like "terse" languages - less typing and lots
>>>> of room left over for comments at the ends of the lines.
>>>
>>> Sounds like assembler ;-)
>>
>>
>> YES ! :-)
>>
>> ASM ... MMmmmmmmm !
>>
>>
>>> It’s too easy to write tricky code with side-effects in C. COBOL might not
>>> be as self-documenting as advertised, but the operation of each statement
>>> is pretty obvious and easily understood.
>>
>> So ... COBOL is for BAD PROGRAMMERS who can't foresee
>> downstream consequences hmmm ??? ;-)
>>
>
> No, COBOL is for the NEXT poor bastard who has to look at your code and
> try to figure out what the heck you were trying to do. The more “concise” a
> language is, the more write-only it tends to be.

THAT'S why 60-75% of my programs are expository COMMENTS
and little TUTORIALS. YOU can EXPLAIN the code a LOT
better than any code can explain itself.

Even my ASM ... every line has a comment, an ongoing
narrative of what's happening and why. Based on that
you could translate it into a dozen higher-level
languages.

And then I see "examples" with 200 lines of 'C' or
whatever with like THREE cryptic comments. The rest
is apparently all Magic ....

On 7/25/22 6:52 PM, Charlie Gibbs wrote:
> On 2022-07-25, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>
>>> On 7/23/22 6:23 PM, Peter Flass wrote:
>>>
>>>> It’s too easy to write tricky code with side-effects in C. COBOL might not
>>>> be as self-documenting as advertised, but the operation of each statement
>>>> is pretty obvious and easily understood.
>>>
>>> So ... COBOL is for BAD PROGRAMMERS who can't foresee
>>> downstream consequences hmmm ??? ;-)
>>
>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>> try to figure out what the heck you were trying to do. The more “concise” a
>> language is, the more write-only it tends to be.
>
> I've cleaned up some pretty horrid COBOL code. Overly-verbose and
> convoluted code can be just as bad as something overly concise.

I would not even begin to deny that Truth.

> A sufficiently determined programmer can write unreadable code
> in any language. Convoluted code with no comments is even worse.
> Convoluted code with outdated, incorrect comments is worse still.

SOME do it INTENTIONALLY - "job security" or pure ego
perhaps.

Hey, there's always Brainfuck .......

The vast bulk of my code is COMMENTS, lucid explanations,
an ongoing narrative of every step. No code can document
itself better than the programmer can whether it's ASM or
COBOL or LISP or whatever bizarre paradigm. Might take one
line, or 50, to explain what's going on and why.

On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:
> On 7/25/22 1:36 AM, Charlie Gibbs wrote:
>> On 2022-07-24, 25B.Z959 <25B.Z959@nada.net> wrote:
>>
>>> FORTRAN is still pretty widely used also, esp in academic
>>> and engineering environments, mostly due to the huge volume
>>> of proven hard-core math routines which nobody wants to
>>> re-write.
>>
>> Many rivals, with the benefit of hindsight, have crossed
>> swords with the old workhorse! Yet FORTRAN gallops on,
>> warts and all, more transportable than syphilis, fired
>> by a bottomless pit of working subprograms.
>> -- Stan Kelly-Bootle: The Devil's DP Dictionary
>>
>
> Fully agree ... NOBODY wants to re-invent it - and
> those subs are LONG-PROVEN while replacements would
> not be able to make such a claim.
>
> in EXACT locations on the "punch card" DOES make it
> all much nicer.

++

--
greymausg@mail.com
"Are you sure that you can live on your investments after retirement?
If not, send us all your money."

On 7/25/22 1:45 AM, Charlie Gibbs wrote:
> On 2022-07-25, 25B.Z959 <25B.Z959@nada.net> wrote:
>
>> I was always able to find smaller outfits where Fast,
>> Efficient and Creative was coveted and appreciated.
>> I could identify Needs they didn't know existed and
>> act on them. The checks weren't quite as big - but ....
>
> I've always gravitated toward smaller outfits . When I left $BIGCORP
> for a smaller one, the hiring personnel director was baffled that
> I would come to a job that paid less. But I got my sanity back,
> and since the new establishment was closer to home, I saved $200
> per month on gas plus a lot of commute time.
>
> (Ten years later that outfit went Dilbert too, but that's another story.)

They all go Dilbert, must be a human/corporate-nature thing,
after awhile ... migrate to start-ups with exotic needs. That
keeps it interesting. I haven't felt like I was *WORKING A
JOB* in 40 years.

One of the bosses saw a Digital Signage example - and wanted
one ... but I couldn't find a decent cheap/free example. So
I wrote one in Python. Then I re-wrote it it Laz/FPC even
better and snappier and more capable. Runs on a rPI
velcro-ed to a Big Screen - you can even take it off
premises, web interface, assemble/arrange yer slide deck.
Some very bad/redundant PHP/HTML involved. FUN !

The mechanic wanted a working maint program - which
was PROMISED by a company as part of a larger package
TWO YEARS AGO and there's no sign of it. A few days
with Laz/FPC and he's got a flexible GUI app that
uses a PICK-style ascii-delimited multivalue database.
FUN ! Then the FORTRAN utility that can translate it
into several formats easy to eventually import into
several kinds of databases. FUN !

I've always loved making exotic dataloggers - micro-controllers
and hand-wired boards, unique sensors. Programming Meets Real
World. Admittedly devices like HOBO loggers can do a lot with
micro-power - and teeny little chips only robots can deal with -
but they tend to be oriented around a handful of "standard"
measurements/methods. What if you need something "different" ?
Well, you MAKE IT YOURSELF. (go with the SEEED LiPo/Solar
chargers, they hold the right output voltage regardless of
solar influx) How do you get +/- 2mm accuracy out of distance
sensors rated for +/- 10mm accuracy ? FUN !

Admittedly, I'm a fan of the immortal Steve Ciarcia who always
said his favorite programming language was "Solder". Amazing
what you can accomplish with a few parts and logic gates ...
stuff even affordable DSP chips will suffer to do ... and
there weren't any DSP chips for most of my career.

Consider eyes - they are little brains unto themselves. They
prep, qualify, quantify, format, "DSP", comment, the raw
input all by themselves before sending the condensed study
on to the brain. A very smart peripheral that makes the
main system MUCH more efficient and responsive.

And I got six figures, insurance and a retirement plan and
occasional peer awards for all this fun :-)

Smaller CAN be bigger. Find a niche you can LOVE.

But if you just HAVE to have the biggest mini-mansion
on the block and $125,000 matched Hiz/Herz SUVs and
the gigantic loan payments that come with it ... well ...
you may have to *WORK A HATEFUL JOB* for pointy-haired
bosses ... sorry .........

On 2022-07-26 01:42, Dan Espen wrote:
> Johnny Billquist <bqt@softjar.se> writes:
>
>> On 2022-07-24 00:23, Peter Flass wrote:
>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>> Sometimes that IS a factor ... you have to have people who
>>>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>>
>>>
>>> IMNSHO, COBOL. C is a terrible language for those types of
>> language. Things
>>> that are so dimple in COBOL, like moving a character string with blank
>>> fill, or formatting numeric output, requires calling subroutines in
>> C, and
>>> lack of length checking on string moves is a recipe for disaster.
>> This is one of the weirder arguments I've ever seen:
>> "requires calling a subroutine in C". As if that somehow is a problem?
>> Not to mention it's a function, and not a subroutine. Any claim of
>> "used the language quite a bit" sounds hollow after that.
>>
>> A statement to move a character string in COBOL will in the end be a
>> subroutine call as well.
>
> And why do you think that?
>
> I've sure seen lots of COBOL MOVE instructions generate a single
> hardware instruction.

Depends on the compiler and hardware, and so on...
Which actually leads to the point that the same is true in C.
You might think you are calling a function like strncpy(). And you are,
on an abstract level. However, modern C compilers understands what this
is, and will in fact insert the required code directly in the
instruction stream, which, again depending on the hardware, might end up
being a single instruction.

So in which way was COBOL better than C? In the end, claiming
superiority of a language based on that one have a function, while the
other have it as a statement is about as silly an argument as I have
ever seen. And all the extra claims to support that view are even sillier.

Johnny

On 26/07/2022 09:48, Johnny Billquist wrote:
> On 2022-07-26 01:42, Dan Espen wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>
>>> On 2022-07-24 00:23, Peter Flass wrote:
>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>>     Sometimes that IS a factor ... you have to have people who
>>>>>     can write it. But 1990 ... IMHO it should have been 'C'.
>>>>>
>>>>
>>>> IMNSHO, COBOL. C is a terrible language for those types of
>>>    language. Things
>>>>    that are so dimple in COBOL, like moving a character string with
>>>> blank
>>>> fill, or formatting numeric output, requires calling subroutines in
>>>    C, and
>>>> lack of length checking on string moves is a recipe for disaster.
>>> This is one of the weirder arguments I've ever seen:
>>> "requires calling a subroutine in C". As if that somehow is a problem?
>>> Not to mention it's a function, and not a subroutine. Any claim of
>>> "used the language quite a bit" sounds hollow after that.
>>>
>>> A statement to move a character string in COBOL will in the end be a
>>> subroutine call as well.
>>
>> And why do you think that?
>>
>> I've sure seen lots of COBOL MOVE instructions generate a single
>> hardware instruction.
>
> Depends on the compiler and hardware, and so on...
> Which actually leads to the point that the same is true in C.
> You might think you are calling a function like strncpy(). And you are,
> on an abstract level. However, modern C compilers understands what this
> is, and will in fact insert the required code directly in the
> instruction stream, which, again depending on the hardware, might end up
> being a single instruction.
>
> So in which way was COBOL better than C? In the end, claiming
> superiority of a language based on that one have a function, while the
> other have it as a statement is about as silly an argument as I have
> ever seen. And all the extra claims to support that view are even sillier.
>
>   Johnny
Value judgements depend on ones ethical standpoint.

COBOL allowed teams of relatively untechnical people to create and
maintain large programs in a disciplined way. It allowed efficient use
of limited memory and good control over formatted printouts.

Its downside was massively large source code, and inability to get close
to the bare metal.

C is the exact opposite, terse, machine level assembler but faster
coded. It exactly suits a technically aware person who knows exactly
what they are doing and is capable of minding his on Ps and Qs.

Yer pays yer money...
--
Climate Change: Socialism wearing a lab coat.

Johnny Billquist <bqt@softjar.se> writes:

> On 2022-07-26 01:42, Dan Espen wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>
>>> On 2022-07-24 00:23, Peter Flass wrote:
>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>> Sometimes that IS a factor ... you have to have people who
>>>>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>>>
>>>>
>>>> IMNSHO, COBOL. C is a terrible language for those types of
>>> language. Things
>>>> that are so dimple in COBOL, like moving a character string with blank
>>>> fill, or formatting numeric output, requires calling subroutines in
>>> C, and
>>>> lack of length checking on string moves is a recipe for disaster.
>>> This is one of the weirder arguments I've ever seen:
>>> "requires calling a subroutine in C". As if that somehow is a problem?
>>> Not to mention it's a function, and not a subroutine. Any claim of
>>> "used the language quite a bit" sounds hollow after that.
>>>
>>> A statement to move a character string in COBOL will in the end be a
>>> subroutine call as well.
>> And why do you think that?
>> I've sure seen lots of COBOL MOVE instructions generate a single
>> hardware instruction.
>
> Depends on the compiler and hardware, and so on...
> Which actually leads to the point that the same is true in C.
> You might think you are calling a function like strncpy(). And you
> are, on an abstract level. However, modern C compilers understands
> what this is, and will in fact insert the required code directly in
> the instruction stream, which, again depending on the hardware, might
> end up being a single instruction.
>
> So in which way was COBOL better than C? In the end, claiming
> superiority of a language based on that one have a function, while the
> other have it as a statement is about as silly an argument as I have
> ever seen. And all the extra claims to support that view are even
> sillier.

This is all true, an IBM mainframe C compiler CAN generate a single
instruction for a memcpy or strncpy. Providing the compiler can tell
the length of the move at compile time. Something that is a lot more
likely for COBOL than C.

For IBM mainframes the COBOL compiler is going to be way more efficient
than C because the COBOL compiler is way more likely to be using packed
decimal.

--
Dan Espen

The Natural Philosopher <tnp@invalid.invalid> writes:
> C is the exact opposite, terse, machine level assembler but faster
> coded.

“Assembler” is a terrible mental model for C.

richard@sfere:~/junk$ cat t.c
int f(int *ptr) {
int r = *ptr;
if(!ptr)
return 0;
return r;
}
richard@sfere:~/junk$ gcc -O2 -c t.c && objdump -dMintel t.o

t.o: file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <f>:
0: 8b 07 mov eax,DWORD PTR [rdi]
2: c3 ret

If C really was some kind of ‘portable assembler’, the compiler would
preserve the test of ptr even though it follows the indirect read.

In C as actually specified, the compiler is free to remove it, and
compilers do just that.

In a user space application this mistake just leads to a crash; in the
Linux kernel a variant of it lead to CVE-2009-1897.

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

On Tue, 26 Jul 2022 14:13:56 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

> The Natural Philosopher <tnp@invalid.invalid> writes:
> > C is the exact opposite, terse, machine level assembler but faster
> > coded.
>
> “Assembler” is a terrible mental model for C.
>
> richard@sfere:~/junk$ cat t.c
> int f(int *ptr) {
> int r = *ptr;

If ptr is 0 this is undefined behaviour aka probably SEGV.

> if(!ptr)

Did you mean !*ptr ?

> return 0;
> return r;

Or is it counting on ptr not really being followed until here ?

> Disassembly of section .text:
>
> 0000000000000000 <f>:
> 0: 8b 07 mov eax,DWORD PTR [rdi]
> 2: c3 ret

That would be consistent with optimising out a test for *ptr

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

Ahem A Rivet's Shot <steveo@eircom.net> writes:
>On Tue, 26 Jul 2022 14:13:56 +0100
>Richard Kettlewell <invalid@invalid.invalid> wrote:
>
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>> > C is the exact opposite, terse, machine level assembler but faster
>> > coded.
>>
>> “Assembler” is a terrible mental model for C.
>>
>> richard@sfere:~/junk$ cat t.c
>> int f(int *ptr) {
>> int r = *ptr;
>
> If ptr is 0 this is undefined behaviour aka probably SEGV.

To be fair, this was an actual example from the linux kernel a few
years ago.

Ahem A Rivet's Shot <steveo@eircom.net> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>> C is the exact opposite, terse, machine level assembler but faster
>>> coded.
>>
>> “Assembler” is a terrible mental model for C.
>>
>> richard@sfere:~/junk$ cat t.c
>> int f(int *ptr) {
>> int r = *ptr;
>
> If ptr is 0 this is undefined behaviour aka probably SEGV.

Please see the remarks you snipped. If *ptr faults then the likely
outcome is a crash; but in some environments that does not happen.

>> if(!ptr)
>
> Did you mean !*ptr ?

No, I did not.

>> return 0;
>> return r;
>
> Or is it counting on ptr not really being followed until here ?

No, the code is buggy (the indirection and the test are the wrong way
around). But it’s a bug that happened in real life and the outcome is
not someone working with the ‘portable assembler’ mental model of C
would expect.

>> Disassembly of section .text:
>>
>> 0000000000000000 <f>:
>> 0: 8b 07 mov eax,DWORD PTR [rdi]
>> 2: c3 ret
>
> That would be consistent with optimising out a test for *ptr

Sure, but that’s not the test found in the source. It has optimized out
the if(!ptr) return 0.

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

On 26/07/2022 14:13, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> C is the exact opposite, terse, machine level assembler but faster
>> coded.
>
> “Assembler” is a terrible mental model for C.
>
> richard@sfere:~/junk$ cat t.c
> int f(int *ptr) {
> int r = *ptr;
> if(!ptr)
> return 0;
> return r;
> }
> richard@sfere:~/junk$ gcc -O2 -c t.c && objdump -dMintel t.o
>
> t.o: file format elf64-x86-64
>
>
> Disassembly of section .text:
>
> 0000000000000000 <f>:
> 0: 8b 07 mov eax,DWORD PTR [rdi]
> 2: c3 ret
>
> If C really was some kind of ‘portable assembler’, the compiler would
> preserve the test of ptr even though it follows the indirect read.

Well C when I learnt it would have done just that. Today its full of
SmartShit™ because computer scientists got their hands on it and tried
to second guess what you really meant rather than what you actually wrote.

And that example is precisely the sort of coding that wasn't done by
someone who knew what they were doing

int f(int *ptr)
{
return(ptr? *ptr:0);
}
Is clearer and absolutely implies the ptr needs to be tested in order to
determine the result.

And it avoids trying to access the contents of a null pointer, which
might cause issues
>
> In C as actually specified, the compiler is free to remove it, and
> compilers do just that.
>
I don't see why. The return value is conditional on the test of ptr.

To me that looks like bad code and a compiler bug

> In a user space application this mistake just leads to a crash; in the
> Linux kernel a variant of it lead to CVE-2009-1897.
>
Whoever wrote that code needs sacking, You do not reference memory
pointers that may be null.

Nor should a compiler assume that if a pointer has been referenced it is
therefore not null.

--
The lifetime of any political organisation is about three years before
its been subverted by the people it tried to warn you about.

Anon.

On 26/07/2022 15:52, Richard Kettlewell wrote:
> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>> C is the exact opposite, terse, machine level assembler but faster
>>>> coded.
>>>
>>> “Assembler” is a terrible mental model for C.
>>>
>>> richard@sfere:~/junk$ cat t.c
>>> int f(int *ptr) {
>>> int r = *ptr;
>>
>> If ptr is 0 this is undefined behaviour aka probably SEGV.
>
> Please see the remarks you snipped. If *ptr faults then the likely
> outcome is a crash; but in some environments that does not happen.
>
>>> if(!ptr)
>>
>> Did you mean !*ptr ?
>
> No, I did not.
>
>>> return 0;
>>> return r;
>>
>> Or is it counting on ptr not really being followed until here ?
>
> No, the code is buggy (the indirection and the test are the wrong way
> around). But it’s a bug that happened in real life and the outcome is
> not someone working with the ‘portable assembler’ mental model of C
> would expect.

Once you introduce a bug and have a buggy compiler, that's exactly what
you do expect.

Carrying a mental model in assembler, what that code is , is to lead the
contents of a reference which may be null, then test if the reference is
actually null, and pass that reference contents or null back.
At assembly level that is pure nonsense. There is no point in testing a
pointer for null if you have already referenced it.

The fact that you have been able to reference it without a segfault
shows it is probably not null.
So the first point is that the actual code is crap. Written by someone
who didn't know what they were doing.
The second point is that the compiler is certainly behaving in a
questionable manner too.

--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

On 26/07/2022 16:20, The Natural Philosopher wrote:
> On 26/07/2022 15:52, Richard Kettlewell wrote:
>> Ahem A Rivet's Shot <steveo@eircom.net> writes:
>>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>>>> C is the exact opposite, terse, machine level assembler but faster
>>>>> coded.
>>>>
>>>> “Assembler” is a terrible mental model for C.
>>>>
>>>>      richard@sfere:~/junk$ cat t.c
>>>>      int f(int *ptr) {
>>>>        int r = *ptr;
>>>
>>>     If ptr is 0 this is undefined behaviour aka probably SEGV.
>>
>> Please see the remarks you snipped. If *ptr faults then the likely
>> outcome is a crash; but in some environments that does not happen.
>>
>>>>        if(!ptr)
>>>
>>>     Did you mean !*ptr ?
>>
>> No, I did not.
>>
>>>>          return 0;
>>>>        return r;
>>>
>>>     Or is it counting on ptr not really being followed until here ?
>>
>> No, the code is buggy (the indirection and the test are the wrong way
>> around). But it’s a bug that happened in real life and the outcome is
>> not someone working with the ‘portable assembler’ mental model of C
>> would expect.
>
> Once you introduce a bug and have a buggy compiler, that's exactly what
> you do expect.
>
> Carrying a mental model in assembler, what that code is , is to lead the
> contents of a reference which may be null, then test if the reference is
> actually null, and pass that reference contents or null back.
> At assembly level that is pure nonsense. There is no point in testing a
> pointer for null if you have already referenced it.
>
> The fact that you have been able to reference it without a segfault
> shows it is probably not null.

I think the point was that some OS (or is it CPU architecture) allows
you to read from the NULL memory address. I've no idea which one, but
presumably one does.

If the read from the NULL address throws a fault, then the C and
assembler will be equivalent.

> So the first point is that the actual code is crap. Written by someone
> who didn't know what they were doing.
> The second point is that the compiler is certainly behaving in a
> questionable manner too.

C says the operation is undefined. I don't use C. Just thinking about it
makes me feel queezy.

Pancho <Pancho.Jones@proton.me> writes:
>On 26/07/2022 16:20, The Natural Philosopher wrote:
>> On 26/07/2022 15:52, Richard Kettlewell wrote:

>> The fact that you have been able to reference it without a segfault
>> shows it is probably not null.
>
>I think the point was that some OS (or is it CPU architecture) allows
>you to read from the NULL memory address. I've no idea which one, but
>presumably one does.

The legacy BSD operating systems marked page zero of the virtual address
space as READ-ONLY and initialized the entire page with zeros. Trying
to store through a NULL pointer would fault, but loads would return zero.

Took a fair amount of work to fix BSD utilities to work on System V due
to this.

For microcontrollers etc that don't have virtual memory, address zero
was always legal.

In early processors, there were often registers located in the first
page of memory (e.g. the autoincrement memory locations in the PDP-8).

On 26/07/2022 16:12, The Natural Philosopher wrote:
> Well C when I learnt it would have done just that. Today its full of
> SmartShit™ because computer scientists got their hands on it and
> tried to second guess what you really meant rather than what you
> actually wrote.

Actually, it's rather the opposite. If you switch on "-O2", the
compiler will assume that you mean what you wrote.

[Richard K]:
>> In C as actually specified, the compiler is free to remove it, and
>> compilers do just that.
> I don't see why. The return value is conditional on the test of ptr.

If "ptr" is 0, then the behaviour is undefined. So if your code
crashes and burns, you have no-one to blame but yourself.

> To me that looks like bad code

Certainly a bug. Characterising it as "bad code" is a step further.
There are worse programming sins than perpetrating a typo that should be
detected during testing. Including the sin of /not/ detecting it during
testing. But there are worse sins even than that.

> and a compiler bug

Not so. The compiler has simply assumed ["-O2", remember] that
you want your code to run as fast as possible. Once you invoke undefined
behaviour, anything that happens is fair game. Don't blame the compiler
for bugs in the program.

> Whoever wrote that code needs sacking, You do not reference memory
> pointers that may be null.

If every programmer who ever perpetrated a bug was sacked, there
would not be a single [useful] programmer in employment.

> Nor should a compiler assume that if a pointer has been referenced it
> is therefore not null.

Whether a compiler "should" assume that is a matter of opinion.
But the compiler is /entitled/ to assume that, because if it is null then
the behaviour on dereferencing was undefined, and it scarcely matters,
/except as a courtesy to the user/, whether the actual behaviour is to
print a message saying "Yah, boo, sucks, you dereferenced a null pointer"
and halt or simply to let the program continue on its merry way until
Something Bad happens.

If you need nice behaviour, then run your programs with compilers
that build in checks against illegal dereferencing, out-of-bounds indexing,
uninitialised variables, and so on. If you don't, then feel free to go for
optimisation that removes all the checks.

Of course, what sensible programmers do is to test their code
with checks switched on, and when satisfied switch them off. Even then,
we should remember Dijkstra; switching checks off in production code is
like using water wings when splashing around in the pool and discarding
them when swimming out to sea.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Bull

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 26/07/2022 14:13, Richard Kettlewell wrote:
>> In C as actually specified, the compiler is free to remove it, and
>> compilers do just that.
>
> I don't see why. The return value is conditional on the test of ptr.
>
> To me that looks like bad code and a compiler bug

It’s not a compiler bug. It’s permitted by the language spec as it’s
stood for the last few decades.

>> In a user space application this mistake just leads to a crash; in the
>> Linux kernel a variant of it lead to CVE-2009-1897.
>
> Whoever wrote that code needs sacking, You do not reference memory
> pointers that may be null.

If you sacked every programmer who created a bug there’d be none
left. (Maybe not such a bad thing.) But you’re missing the point, which
is that the ‘assembler’ model you proposed for C doesn’t match reality.

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

According to 25B.Z959 <25B.Z959@nada.net>:
> Even my ASM ... every line has a comment, an ongoing
> narrative of what's happening and why. Based on that
> you could translate it into a dozen higher-level
> languages.

i += 2; // Add 1 to i.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:

> The "modern" design where stuff doesn't have to be
> in EXACT locations on the "punch card" DOES make it
> all much nicer.

On the other hand, fixed locations means you know exactly
where to look. Each method has its advantages and
disadvantages - although I admit that I've converted
to CSV for just about everything.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:

> Smaller CAN be bigger. Find a niche you can LOVE.
>
> But if you just HAVE to have the biggest mini-mansion
> on the block and $125,000 matched Hiz/Herz SUVs and
> the gigantic loan payments that come with it ... well ...
> you may have to *WORK A HATEFUL JOB* for pointy-haired
> bosses ... sorry .........

But that's Success. Don't you want Success?

I've spent my entire career avoiding Success.
It's much more fun that way.

BTW on Peter Gabriel's album _So_, the lyrics for
_Big Time_ are accompanied by the note "suc cess".

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2022-07-26, 25B.Z959 <25B.Z959@nada.net> wrote:

> On 7/25/22 4:55 PM, Peter Flass wrote:
>
>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>
>>> So ... COBOL is for BAD PROGRAMMERS who can't foresee
>>> downstream consequences hmmm ??? ;-)
>>
>> No, COBOL is for the NEXT poor bastard who has to look at your code and
>> try to figure out what the heck you were trying to do. The more “concise”
>> a language is, the more write-only it tends to be.
>
> THAT'S why 60-75% of my programs are expository COMMENTS
> and little TUTORIALS. YOU can EXPLAIN the code a LOT
> better than any code can explain itself.
>
> Even my ASM ... every line has a comment, an ongoing
> narrative of what's happening and why. Based on that
> you could translate it into a dozen higher-level
> languages.

I started doing exactly that in assembly language, and still do it in C.

> And then I see "examples" with 200 lines of 'C' or
> whatever with like THREE cryptic comments. The rest
> is apparently all Magic ....

"My code is so readable it doesn't need comments."

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2022-07-26, Dan Espen <dan1espen@gmail.com> wrote:

> For IBM mainframes the COBOL compiler is going to be way more efficient
> than C because the COBOL compiler is way more likely to be using packed
> decimal.

As long as you're referring to data fields, that's true.
But I once knocked 30% off a program's execution time by
simply changing all subscripts from COMP-3 (packed decimal)
to COMP-4 (binary). (The original author obviously had
no real-world experience.)

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

On 2022-07-26, John Levine <johnl@taugh.com> wrote:

> According to 25B.Z959 <25B.Z959@nada.net>:
>
>> Even my ASM ... every line has a comment, an ongoing
>> narrative of what's happening and why. Based on that
>> you could translate it into a dozen higher-level
>> languages.
>
> i += 2; // Add 1 to i.

Well, it might have done so in the original version -
which is why keeping comments up to date is vital.

(And yes, comments that trivial are a waste of time.
But that's another topic.)

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.

Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-07-26 01:42, Dan Espen wrote:
>> Johnny Billquist <bqt@softjar.se> writes:
>>
>>> On 2022-07-24 00:23, Peter Flass wrote:
>>>> 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>> Sometimes that IS a factor ... you have to have people who
>>>>> can write it. But 1990 ... IMHO it should have been 'C'.
>>>>>
>>>>
>>>> IMNSHO, COBOL. C is a terrible language for those types of
>>> language. Things
>>>> that are so dimple in COBOL, like moving a character string with blank
>>>> fill, or formatting numeric output, requires calling subroutines in
>>> C, and
>>>> lack of length checking on string moves is a recipe for disaster.
>>> This is one of the weirder arguments I've ever seen:
>>> "requires calling a subroutine in C". As if that somehow is a problem?
>>> Not to mention it's a function, and not a subroutine. Any claim of
>>> "used the language quite a bit" sounds hollow after that.
>>>
>>> A statement to move a character string in COBOL will in the end be a
>>> subroutine call as well.
>>
>> And why do you think that?
>>
>> I've sure seen lots of COBOL MOVE instructions generate a single
>> hardware instruction.
>
> Depends on the compiler and hardware, and so on...
> Which actually leads to the point that the same is true in C.
> You might think you are calling a function like strncpy(). And you are,
> on an abstract level. However, modern C compilers understands what this
> is, and will in fact insert the required code directly in the
> instruction stream, which, again depending on the hardware, might end up
> being a single instruction.
>
> So in which way was COBOL better than C? In the end, claiming
> superiority of a language based on that one have a function, while the
> other have it as a statement is about as silly an argument as I have
> ever seen. And all the extra claims to support that view are even sillier.
>

Better for what? C is, or at least used to be, excellent at generating very
tight code with little overhead. From what I’ve seen, I believe the
overhead has crept back in. COBOL is excellent for programs that might not
need to be the fastest, but are expected to be running for DECADES and
maintained by a lot of different people of wildly different skill levels.

If I were writing an OS, I’s choose C over COBOL (actually, I’d choose PL/I
but that’s another argument). If I were writing a payroll system, COBOL
might be a better choice.

--
Pete