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

Dan Espen <dan1espen@gmail.com> wrote:
> 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.
>
>

XLC has functions for handling packed decimal. I don’t know about current
mainframe C.

--
Pete

Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> 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.

The programmer makes assumptions based on what he/she knows. Presumably the
original author might “know” that ptr will never be zero (previously
tested, data would not allow it, etc.) This is why maintenance is such a
minefield. I have been bitten by my own code when I changed it years after
originally written.

Actually, I wouldn’t WANT the compiler to test for zero here. If you want
it, do it yourself.

--
Pete

Pancho <Pancho.Jones@proton.me> wrote:
> 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.
>

In a lot of cases, the contents of low memory, including address 0, are
readable. In MVS (etc.) low memory is the Prefixed Storage Area (PSA) which
is a useful control block. Some, or all?, Unices don’t map page zero, so
you get a SIGSEGV trying to access it, but this isn’t universally true.

--
Pete

On 25/07/2022 21:55, Peter Flass wrote:
> 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.

Ah, you've seen APL then?

Andy

On 26/07/2022 21:43, Charlie Gibbs wrote:
> 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.)
>
The useful comments don't say _what_ you're doing, they say _why_.

Andy

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

For some values of one ;-)

--
Pete

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> 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."
>

I comment most lines, and include the text of the spec I’m working from as
a block comment where appropriate.

--
Pete

On 26/07/2022 17:17, Scott Lurndal wrote:
> 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).

The first system I learned assembler on was a DECSystem10. That had the
registers mapped into the first 16 memory addresses, so an access via a
null pointer would have given the the contents of the first register.

OTOH its memory was all 36 bit words, with magic to access strings. I
don't think C would have worked at all well.

Andy

On Tue, 26 Jul 2022 13:49:44 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> > 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.
>
> The programmer makes assumptions based on what he/she knows. Presumably
> the original author might “know” that ptr will never be zero (previously

Programmer tests ptr for 0 in the next statement. Buggy code!

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

On Tue, 26 Jul 2022 21:52:32 +0100
Vir Campestris <vir.campestris@invalid.invalid> wrote:

> On 25/07/2022 21:55, Peter Flass wrote:
> > 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.
>
> Ah, you've seen APL then?

The most unreadable language yet has to be whitespace:

https://en.wikipedia.org/wiki/Whitespace_(programming_language)

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

On Tue, 26 Jul 2022 21:53:36 +0100
Vir Campestris <vir.campestris@invalid.invalid> wrote:

> The useful comments don't say _what_ you're doing, they say _why_.

This!

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

On Tue, 26 Jul 2022 21:58:53 +0100
Vir Campestris <vir.campestris@invalid.invalid> wrote:

> The first system I learned assembler on was a DECSystem10. That had the
> registers mapped into the first 16 memory addresses, so an access via a
> null pointer would have given the the contents of the first register.
>
> OTOH its memory was all 36 bit words, with magic to access strings. I
> don't think C would have worked at all well.

You might be surprised - it seems gcc was got working on it a
couple of decades ago.

http://pdp10.nocrew.org/gcc/

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

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

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

Now the right solution is

USAGE IS INDEX

Of course you don't use packed decimal for indexes. USAGE DISPLAY is no
good either. But early on most of us knew to use COMP before usage
index was invented.

--
Dan Espen

Peter Flass <peter_flass@yahoo.com> writes:

> Dan Espen <dan1espen@gmail.com> wrote:
>> 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.
>
> XLC has functions for handling packed decimal. I don’t know about current
> mainframe C.

Back when I was working the situation was that C had one way of doing
it, C++ had another. Neither was a clean solution in my opinion.

--
Dan Espen

On 7/26/22 3:38 PM, John Levine 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.

Um ... that'd add TWO to i .......

i++ ; add 1 to i ... ++i++ might add two, depending
on the compiler.

(Intel 8051 ... assume 'i' is ushort value at address 0x0100)

MOV 0x0100,a ... copy contents of address 0x100 to accumulator
INC a ... increment accumulator by one
MOV a, 0x0100 ... copy accumulator to address 0x0100

- OR JUST -

INC 0x0100 ... increment byte value found at 0x0100,
... kinda actually does the above three lines,
... but leaves accumulator as-is.

Gets more complicated incrementing an integer var, gotta
ADD so the overflow flag comes into play. INC does not
affect the overflow flag, it just rolls-over to 0x00 if
you inc an 0xFF

On 7/26/22 4:53 PM, Vir Campestris wrote:
> On 26/07/2022 21:43, Charlie Gibbs wrote:
>> 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.)
>>
> The useful comments don't say _what_ you're doing, they say _why_.

'Zactly ... it needs to be a 'narrative' - both WHAT and WHY.
Doesn't matter if it's ASM or COBOL or FORTRAN or Python. If
you or anybody would EVER need to go back and tweak the pgm
it really NEEDS serious commenting. Alas it's kinda RARE to
see this ..... the old "Well *I* know what it's all about NOW"
attitude. Wait a couple years until the boss decides your form
needs some new data fields or entry box #7 moved 10 spaces to
the right 'cause it would 'look nicer' .... :-)

Think of the actual code as 'shorthand' for the story you're
writing whether it's Shakespeare, or "See Spot run !" ....

On 7/26/22 4:43 PM, Charlie Gibbs wrote:
> 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."

There's an old joke about a college prof (and a friend
of mine had one JUST like it) where the prof slams down
five lines of ultra-dense next-level math on the blackboard
then kinda half turns to the class and says "So, obviously ..."

On 7/20/22 6:41 PM, J. Clarke wrote:
> On Mon, 18 Jul 2022 21:26:23 -0400, "25B.Z959" <25B.Z959@nada.net>
> wrote:
>
>> On 7/17/22 4:59 PM, Charlie Gibbs wrote:
>>> [Cross-posted to alt.folklore.computers]
>>>
>>> On 2022-07-17, Dan Espen <dan1espen@gmail.com> wrote:
>>>
>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>>>
>>>>> On 2022-07-17, 25B.Z959 <25B.Z959@nada.net> wrote:
>>>>>
>>>>>> On 7/16/22 8:48 AM, Dan Espen wrote:
>>>>>>
>>>>>>> "25B.Z959" <25B.Z959@nada.net> writes:
>>>>>>>
>>>>>>>> Fortunately, few are so cheap to be using 2-digit dates
>>>>>>>> anymore. Not so in the past - they just assumed 19xx. Saved a
>>>>>>>> little space, easier calx.
>>>>>>>
>>>>>>> There you go, true to form. Now people use 2 digit dates because
>>>>>>> they are cheap.
>>>>>>
>>>>>> You are neglecting Computers Past ..... low speed, low
>>>>>> capacity. You simplified calx, you squeezed-down the data anywhere
>>>>>> you could. I know, I had to do it.
>>>>>
>>>>> Me too. My first job was in an all-card shop. To squeeze things onto
>>>>> an 80-column card, we stored dates in 5 columns as ddmmy. That's
>>>>> right, we only kept the last digit of the year. I started there in
>>>>> 1970, and one of my first assignments was to go through all report
>>>>> programs and change the '6' they inserted in front of the year to '7'.
>>>>
>>>> In an all card shop having more than 1 card for a logical record is a
>>>> problem. Not insurmountable but difficult. I've heard the one digit
>>>> year story in that context but never had to deal with it.
>>>
>>> We used two cards for customer name data, but they didn't have dates
>>> in them, just long names. You're right, having more than one card
>>> for a logical record is a pain in the ass. I use the present tense
>>> because I'm still faced with such files today.
>>
>>
>> Yep - the past IS present ... old records never die, they
>> just become more inconvenient. :-)
>>
>> 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.
>
> And now some poor schmuck in India has to deal with it all.

You can hear them leafing through their manuals as they
ask irrelevant questions ......

I once was looking through one of those sites that list
unsecured webcams (and you'd be amazed how many). One
of them was a tech-support main room in Bangalore. At
(N.American) night you'd see them all lined up at their
PCs ... but N.American DAY ... they all had a little
mat and slept packed-in on the floor. Really.

On 26/07/2022 17:53, Andy Walker wrote:
> 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,

Why is that? memory address of 0 is a valid memory address. At least in
hardware terms.
Does the C language enforce that memory at (page) address 0 is
unaddressable?

--
You can get much farther with a kind word and a gun than you can with a
kind word alone.

Al Capone

On 26/07/2022 21:43, Charlie Gibbs wrote:
> 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."
>
I am in between. Typically I will head a block of code with an
explanation of what it is supposed to do.

I wont bother much in between unless that code looks cryptic to me, and
I try to make it not so. Bearing in mind that compiler optimisation
means you needn't code for speed at source level, but for clarity.

--
Microsoft : the best reason to go to Linux that ever existed.

On Wed, 27 Jul 2022 11:36:37 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 26/07/2022 17:53, Andy Walker wrote:
> > 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,
>
> Why is that? memory address of 0 is a valid memory address. At least in
> hardware terms.

However it usually isn't an accessible one in a protected memory
environment.

> Does the C language enforce that memory at (page) address 0 is
> unaddressable?

No, it simply states that the behaviour of a program is undefined
(by the C standard) once it attempts to access memory that hasn't been
allocated by one of the documented mechanisms in the C standard. What
happens depends on the platform and the compiler.

If you're writing code for a platform where you know what that
behaviour will be and it is the behaviour you want then C will not get in
your way (your compiler might but it should be persuadable) - but you are
warned that the code may behave differently on a different platform.

Note that the C standard does technically allow the compiler or the
compiled program to execute the author but as far as I know this option has
never been implemented - let me know if you find otherwise.

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

On 27/07/2022 11:36, The Natural Philosopher wrote:
[I wrote:]
>> But the compiler is /entitled/ to assume that, because if it is>> null then the behaviour on dereferencing was undefined,
> Why is that? memory address of 0 is a valid memory address. At least
> in hardware terms.

Whether or not that is true depends on your hardware and what
pages [on systems where that is meaningful] have been allocated. But,
rather ...

> Does the C language enforce that memory at (page) address 0 is unaddressable?

... C enforces that 0, as a pointer, is a null pointer and cannot
properly be dereferenced [it can be used for other purposes]. See the C
standard, eg N1570 [C11 -- other C standards are available, but they
haven't changed much in this area over the decades]:

6.3.2.3.3:
" An integer constant expression with the value 0, or such an expression
" cast to type void *, is called a null pointer constant. If a null
" pointer constant is converted to a pointer type, the resulting pointer,
" called a null pointer, is guaranteed to compare unequal to a pointer
" to any object or function. "

and 6.5.3.2.4:
" The unary * operator denotes indirection. ... If an invalid value has
" been assigned to the pointer, the behavior of the unary * operator is
" undefined.[footnote 102] "

where footnote 102 says:
" Among the invalid values for dereferencing a pointer by the unary *
" operator are a null pointer, an address inappropriately aligned for
" the type of object pointed to, and the address of an object after
" the end of its lifetime. "

Whether a null pointer actually "points to address 0" is up to compiler
magic to sort out. After all, the high-level language programmer is not
expected to know where in storage the objects used by the program reside.
Note that the result of dereferencing a null pointer is undefined, rather
than, for example, being defined to halt the program with an error; you
may get away with it, but it's still a bug, and therefore a disaster
waiting to happen.

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

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 26/07/2022 17:53, Andy Walker wrote:
>> 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,
>
> Why is that? memory address of 0 is a valid memory address. At least
> in hardware terms.

You’re still thinking about C as ‘portable assembler’.

> Does the C language enforce that memory at (page) address 0 is
> unaddressable?

It’s not about what it enforces; it’s about what it doesn’t enforce. In
this case, it places no constraints on the implementation’s behavior
when a null pointer (or any other kind of invalid pointer) is
dereferenced. Modern implementations exploit this absence of constraints
in their code generation.

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