Recording the Screen?

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/
Reply to
Dennis Lee Bieber
Loading thread data ...

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.

--
/~\  Charlie Gibbs                  |  They don't understand Microsoft 
\ /        |  has stolen their car and parked 
 Click to see the full signature
Reply to
Charlie Gibbs

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 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

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.

formatting link

--
Joe
Reply to
Joe

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

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

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 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

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 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

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

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

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.

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

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.

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

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

Reply to
Andy Burns

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

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

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/
Reply to
Dennis Lee Bieber

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

--

-TV
Reply to
Tauno Voipio

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:

Reply to
Jim Jackson

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.

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

I've written my own function copyline() - a cross between strcpy() and getline() - to accomplish this.

--
/~\  Charlie Gibbs                  |  They don't understand Microsoft 
\ /        |  has stolen their car and parked 
 Click to see the full signature
Reply to
Charlie Gibbs

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

1980s C compilers any more.

Stephen

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

And please don't top post.

---druck

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

--
?The ultimate result of shielding men from the effects of folly is to  
fill the world with fools.? 
 Click to see the full signature
Reply to
The Natural Philosopher

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.