On Sat, 10 Apr 2021 22:59:57 -0000 (UTC), Martin Gregorie declaimed the following:
I can envision cases where one doesn't want a terminator... Such as overlaying varying data into a formatted line of text rather than building the line piecemeal each time...
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
This is what makes Forth popular in boot loaders, it's one of the shortest paths there is to processor independent code, and when you get there that code is extremely compact.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
There was actually a 'home' computer produced which was based on Forth, though on the Z80 rather than the 6809 which Forth was originally designed to use. It wasn't very successful.
Splort! Forth was designed in the back end of the 1960s a *long* time before there was a Z80 or 6809 - the first implementation was on an IBM-1130 which was quite a different architecture to either of the later micros. The first application was controlling a radio telescope.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
One solution - use calloc to get a zero filled destination and give strncpy n-1 to play with, it's a little prettier than the common approach of using strncpy then shoving a NULL into the last byte just in case.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
If you?re just copying a string to dynamically allocated memory, you can use strdup(); if you?re composing a dynamically allocated string from some more complex set of inputs, asprintf().
Neither are part of the standard C library, but both are straightforward to construct given things that are (and are present in Glibc, and therefore most Pi installations).
And as ever, if possible, use a more sensible language...
Yep - no null is appended of the string is too long for the buffer. A major design mistake IMO.
I'd far rather get a truncated string than an unterminated one because thats less likely to cause secondary errors that can obscure the buffer length error.
Nah, it goes back further than that. I'd always thought it first surfaced on PDP8 minicomputers, but apparently it originated on an IBM 1130 (at least according to Wikipedia it did) and was implemented on 8-bit microcomputers, i.e. the 6800 and 8080 in 1978, a year or two before before the 6809 was released.
On Sun, 11 Apr 2021 08:57:05 +0100, Joe declaimed the following:
That's an anachronism if ever...
FORTH, Inc, itself, was formed in 1973 -- years before the 6809 chip was released. It started on an IBM 1130. MicroFORTH is 1976, on 8080, 6800, Z80, and 1802.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
I doubt the PDP-8. It is a computer addressed with 128 word pages of 12 bits each. It is pretty frustrating to have useable pointers there, and Forth code is just a jumble of pointers. The early Forths were heavily threaded (TIL = Threaded Interpretive Language).
A plea: If one insists on taking over a thread into new territory, then please change the subject? Then the diversion can be skipped by those who are only interested in the original thread.
I don?t want any of truncation, missing termination or overflow. They?re all bad options. I want either an error indicator if the string won?t fit, or (more usually) something that constructs a buffer of suitable size.
I had to type in three weeks of Forth written in 8086 assembler, and get it to talk to the operating system I had been tasked with building..
the chief advantage seemed to me to be its compact nature. Otherwise it was a swine to program in
And being interpreted, the comments ended up in the live program itself. Not good for space.
Ir was a bit like microcode. you stared with primitive hardware and added your own high level instructions. Great hackers language though
But in the end C was as faster and leaner on memory mostly Of course the great divide here is whether languages should help you program better, or prevent you from programming badly
Its the same across the IT industry. Stuff now does what it thought you wanted it to do, not what you actually asked it to do. And that is a recipe for disaster
Code is huge, runs like a dog, and is so complex and full of bugs that in the end one is tempted to throw it away and start again....
--
?The ultimate result of shielding men from the effects of folly is to
fill the world with fools.?
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.