Recording the Screen?

In general one tended to either work in small model - 64K heap and stack IIRC or large model, and the compilers I used didn't mix the two.

In the end when the 32 bit processors arrived it all got rather academic anyway.

What gave me trouble was working with C compilers that barely understood C on 8 bit platforms.

--
Renewable energy: Expensive solutions that don't work to a problem that  
doesn't exist instituted by self legalising protection rackets that  
 Click to see the full signature
Reply to
The Natural Philosopher
Loading thread data ...

... and why re-assembly is not quite the reverse of disassembly.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

Use a language which automates the range checking (i.e. almost everything more modern than C). Computers are good at automating repetetive tasks, humans aren?t.

--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

Some older than C too, LISP springs to mind and of course Smalltalk, the archetype of OO and one of the purest forms, is almost exactly the same age as C.

The lack of range checking and the like in C wasn't because the techniques were unknown, it was a deliberate choice to make a highly efficient language (given the limitations of compilers running on 1960s hardware) that allowed extremely efficient (both memory and time) algorithms (just look at strtok) to be written easily. It was intended to be suitable for writing the core code of operating systems for things like PDP-11s where efficiency matters far more than safety.

Using it for massive commercial applications is simply poor language choice.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

There are a number of literate programming systems from the Knuth Web/Weave/Tangle onwards through Doxygen and JavaDoc.

We have used literate programming for Forth systems for 20 years or so. We stick firmly to a rule that code and documentation are never separated - the documentation is in the source code. Our tool is called DocGen and it produces out in HTML5, Markdown, Texinfo (PDF) or Latex.

I note that whenever I do the documentation for a new package from a third party, I find and correct bugs. In orther words, use of literate programming reduces overall costs.

The manuals for our current Forth systems are done with DocGen and its source is included.

Stephen

--
Stephen Pelc, stephen@vfxforth.com
Reply to
Stephen Pelc

Ah - um ...yes

--
"Corbyn talks about equality, justice, opportunity, health care, peace,  
community, compassion, investment, security, housing...." 
 Click to see the full signature
Reply to
The Natural Philosopher

No language can do that except at run time, and that is cycles used. Whether needed or not.

Consider. you are copying a string from a buffer of known length, in C. The data cannot be bigger than the buffer. So provided your new buffer is of equivalent size you do not need to check.

Only when treating unknown externally (to your program) sourced data do you need to validate and range check length and values.

If you don't do that as a matter of course you should be fired and prevented from programming ever again.

Where I live occasionally people stray out from suburbia: used to having everything told to them in terms of how they must drive, they are oblivious to anything but a road sign. They don't slow down for horses or cyclists or move to the side of the road to let people past on narrow roads. Often they have accidents.

Local residents have a code of practice for roads with no markings indeterminate width, covered in deer, pheasant, rabbits, cyclists and horseriders .

The philosophical point is that by protecting people from the consequences of their own idiocy, they have no idea how to behave in a situation outside their normal.

Perhaps some people are simply too stupid to program a computer, and instead of trying to protect them from that, we should simply proscribe them from writing code.

We have, after all, some sort of rudimentary driving test.

--
"Corbyn talks about equality, justice, opportunity, health care, peace,  
community, compassion, investment, security, housing...." 
 Click to see the full signature
Reply to
The Natural Philosopher

Definitely the right way to do things!

As I said, earlier, I've done the same for C, but did cheat a bit: my Cdocs tool is written in Java and, because I found it produced better documentation if it understood and interpreted preprocessor directives, it includes a parser written using the excellent Coco/R compiler generator.

formatting link

Coco/R is fairly similar to lex+yacc but is a single program rather than separating the scanner from the parser as lex+yacc (or flex+bison) does and it uses EBNF notation to describe the symbols and syntax of the input text.

IIRC I've done the same for Java with the standard javadocs tool, though, sadly, all too often it just shows what an unreadable, uncommented mess the source code is.

On the plus side, I've found that always running my own C through Cdocs and Java through javadocs has considerably improved the readability of generated documentation for my own code and (especially) the usability of my private productivity modules, such as ArgParser, an extended getopt() for Java, and CSV implementations for both C and Java.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

Ah. Loads of Irrelevant Superfluous Parentheses...

and of course

Indeed.

As are most modern languages. You can write shit in any language, some just make it less obvious that you have.

proper specification and structural decomposition should precede any language choice and rigorous testing should follow it. But neither of these seem to be done today - the language is supposed to render both unnecessary.

--
In theory, there is no difference between theory and practice. 
In practice, there is. 
 Click to see the full signature
Reply to
The Natural Philosopher

Forth is completely unintelligible without documentation. It's pretty unintelligible with it.

--
Climate is what you expect but weather is what you get. 
Mark Twain
Reply to
The Natural Philosopher

String handling in bare C requires the heavy use of pointers and pointer arithmetic.

Novices have issues copying strings, a byte at a time and incorrectly incrementing indexes of an array. Many will cut 'n' paste from a book.

An accidental "step out" at the end of a string buffer may go unnoticed and generally be harmless, except for the occasions where strings are not actually strings kept for printing, but are byte buckets (casual arrays) for further processing of the contained data.

Then we find hackers with clever knowledge of novice coding algorithms and how they could be exploited when a buggy loop overruns into memory space that was considered private, but crashing revealing secrets etc ...

formatting link

--
Adrian C
Reply to
Adrian Caspersz

Indeed, but cycles are cheap.

No, you're not. In C you're copying characters from the byte at the start pointer until the last byte you copied contains binary zero, because C strings are null-terminated.

Yes, in C you'd better make sure that whatever 'read a string into buffer' function you use never reads in more than buffersize-1 bytes AND always appends a null character to the string it just read or you'll be in trouble sooner rather than later.

However, you'd still better check receiving buffer sizes when copying or concatenating strings or arrays in strings because the C compiler doesn't check the receiving area size OR that the source for a string copy or append operation is null-terminated.

This is quite unlike Java, which doesn't have this issue because every object, including arrays of primitives, e.g. char[], has a size, which is adjusted as needed to hold whatever is being pumped into it, so no buffer overflows by definition, or COBOL, because all fields have fixed lengths which the compiler honours when compiling MOVE or READ statements.

Neither Java nor COBOL use string termination characters by default.

Thats benign compared with some places.

Back on the '70s when the Hippy Trail to Kathmandhu was still a thing, Turkey had a default road rule: "A traffic accident is ALWAYS the foreigner's fault", based on the reasoning that the accident would not have happened if said foreigner wasn't in Turkey. I've not been there since, so for all I know, that rule still applies.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

Compilers are smarter than you apparently realize. They exploit statically available size information, lift range checks out of loops, eliminate redundant checks, etc. They do all this at least as well as a human, generally better.

Getting humans to do these checks when a computer can do them better instead is a serious misallocation of effort.

That?s very naive. Components of a nontrivial program cannot safely assume that all the components that interact with it are bug-free.

--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

The real problem (to the extent that it is a problem) with C is not that it uses null terminated strings but that it lacks any enforcement of invalid (as in results in undefined behaviour according to the spec) pointer manipulation.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

not

True enough, but for the C buffer overflow issue, the real answer, which nobody, including me, has so far mentioned, is rigorous use of the newer 'strn' library functions in place of the older 'str' functions they replace. Still not a full solution for missing string terminators, of course, not least because 'strn' functions don't force the last char in a buffer to be null, but at least they eliminate buffer overflows stomping on stuff outside the buffer.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

Another write-only language, then. Bit like perl, I suppose.

--
Tim
Reply to
TimS

I think Swiss insurance companies have a similar approach. If you hadn't been out on the road, the accident wouldn't have happened. Ergo, it's your fault.

--
Tim
Reply to
TimS

That's a band-aid not a real solution - primarily because it requires you to know what to pass for 'n' and if you get that wrong bad things happen.

Only if you get 'n' right. A real solution would deprive you of the opportunity to get it wrong.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

Worse, because the whole thing is not only self-defining, but only speaks strict Reverse Polish. Its a lot easier to get into if you already use an HP calculator (I still have an HP28S in everyday use).

However, but its worth playing with an implementation to see how it works and what it can do.

I used to have a version that ran on a 6809 under the Flex OS (Radical I know - as conceived it ran on bare metal). It was surprisingly fast, but the startling thing is that the whole gubbins - user interface, source editor and compiler/assembler - is a heap (literally) of Forth words. There must be 100-200 of them but, and here's the odd bit, only the lowest level 30-40 words were written in assembler. All the rest were written in 100% Forth source. Installing it was just a matter of compiling the assembler words and adding a jump to the root word, and setting up the floppy drive it lived on as a boot disk.

It started up surprisingly fast when you consider that 'starting up' must have consisting of compiling all the non-assembler words into a linked structure before it could issue the first prompt.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

Agreed, but only if the 'n' functions force the last character in the buffer to be null. I still find it odd that that trick was omitted.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.