Recording the Screen?

In GCC 8, if you turn on the -Wall option, it gets so picky that it will flag strncpy() used this way. You can use memcpy() instead, though.

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.

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.

strncpy doesn?t reliably 0-terminate the destination string. For most use cases it?s a mistake.

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.

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.

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.

I heard of them but never saw one

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.

I see "fringe" implementations of strnzcpy() floating around ...

Indeed. I have a private set: stringcat(), stringcopy(), stringlength() with a debug display option built in. I expect it will be extended as needed.

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.

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.

Jim (god, pe> Ahem A Rivet's Shot writes:

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've written my own function copyline() - a cross between strcpy() and getline() - to accomplish this.

Thanks to those who actually responded about literate programming.

The respondents whose knowledge of Forth comes from the 1980s should go back and re-educate yourselves with a modern Forth. I don't use

Stephen

And please don't top post.

---druck

Do you mind awfully if I don't?

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