From paul.winalski at gmail.com Tue Oct 1 01:49:28 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 30 Sep 2024 11:49:28 -0400 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928180559.GF9067@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180559.GF9067@mcvoy.com> Message-ID: [moving to COFF as this has drifted away from Unix] On Sat, Sep 28, 2024 at 2:06 PM Larry McVoy wrote: > I have a somewhat different view. I have a son who is learning to program > and he asked me about C. I said "C is like driving a sports car on a > twisty mountain road that has cliffs and no guard rails. If you want to > check your phone while you are driving, it's not for you. It requires > your full, focussed attention. So that sounds bad, right? Well, if > you are someone who enjoys driving a sports car, and are good at it, > perhaps C is for you." > > If you really want a language with no guard rails, try programming in BLISS. Regarding C and C++ having dangerous language features--of course they do. Every higher-level language I've ever seen has its set of toxic language features that should be avoided if you want reliability and maintainability for your programs. And a set of things to avoid if you want portability. Regarding managed dynamic memory allocation schemes that use garbage collection vs. malloc()/free(), there are some applications where they are not suitable. I'm thinking about real-time programs. You can't have your missle defense software pause to do garbage collection when you're trying to shoot down an incoming ballistic missile. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Oct 1 03:59:49 2024 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 30 Sep 2024 10:59:49 -0700 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180559.GF9067@mcvoy.com> Message-ID: <20240930175949.GI17434@mcvoy.com> On Mon, Sep 30, 2024 at 11:49:28AM -0400, Paul Winalski wrote: > [moving to COFF as this has drifted away from Unix] > > On Sat, Sep 28, 2024 at 2:06???PM Larry McVoy wrote: > > > > I have a somewhat different view. I have a son who is learning to program > > and he asked me about C. I said "C is like driving a sports car on a > > twisty mountain road that has cliffs and no guard rails. If you want to > > check your phone while you are driving, it's not for you. It requires > > your full, focussed attention. So that sounds bad, right? Well, if > > you are someone who enjoys driving a sports car, and are good at it, > > perhaps C is for you." > > > > If you really want a language with no guard rails, try programming in > BLISS. > > Regarding C and C++ having dangerous language features--of course they do. > Every higher-level language I've ever seen has its set of toxic language > features that should be avoided if you want reliability and maintainability > for your programs. And a set of things to avoid if you want portability. > > Regarding managed dynamic memory allocation schemes that use garbage > collection vs. malloc()/free(), there are some applications where they are > not suitable. I'm thinking about real-time programs. You can't have your > missle defense software pause to do garbage collection when you're trying > to shoot down an incoming ballistic missile. That's why I like reference counting. It doesn't have the long pauses that other garbage collection systems have, when the variable goes out of scope, you decrement, last guy frees. Seems pretty simple. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From crossd at gmail.com Tue Oct 1 04:08:58 2024 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Sep 2024 14:08:58 -0400 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930175949.GI17434@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180559.GF9067@mcvoy.com> <20240930175949.GI17434@mcvoy.com> Message-ID: On Mon, Sep 30, 2024 at 2:07 PM Larry McVoy wrote: > On Mon, Sep 30, 2024 at 11:49:28AM -0400, Paul Winalski wrote: > > [moving to COFF as this has drifted away from Unix] > > > > On Sat, Sep 28, 2024 at 2:06???PM Larry McVoy wrote: > > > > > > > I have a somewhat different view. I have a son who is learning to program > > > and he asked me about C. I said "C is like driving a sports car on a > > > twisty mountain road that has cliffs and no guard rails. If you want to > > > check your phone while you are driving, it's not for you. It requires > > > your full, focussed attention. So that sounds bad, right? Well, if > > > you are someone who enjoys driving a sports car, and are good at it, > > > perhaps C is for you." > > > > > > If you really want a language with no guard rails, try programming in > > BLISS. > > > > Regarding C and C++ having dangerous language features--of course they do. > > Every higher-level language I've ever seen has its set of toxic language > > features that should be avoided if you want reliability and maintainability > > for your programs. And a set of things to avoid if you want portability. > > > > Regarding managed dynamic memory allocation schemes that use garbage > > collection vs. malloc()/free(), there are some applications where they are > > not suitable. I'm thinking about real-time programs. You can't have your > > missle defense software pause to do garbage collection when you're trying > > to shoot down an incoming ballistic missile. > > That's why I like reference counting. It doesn't have the long pauses > that other garbage collection systems have, when the variable goes out > of scope, you decrement, last guy frees. Seems pretty simple. The problem with ref counting is that it's not completely general; circular data structures will never be collected, even if all external references to them disappear. That said, reference counting is a really powerful technique; it's just that it must be used carefully. - Dan C. From jcapp at anteil.com Tue Oct 1 06:12:00 2024 From: jcapp at anteil.com (Jim Capp) Date: Mon, 30 Sep 2024 16:12:00 -0400 (EDT) Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: Message-ID: <5182549.12624.1727727120300.JavaMail.root@zimbraanteil> Moving to COFF ,.. From: "Rich Salz" To: "TUHS main list" Cc: "Douglas McIlroy" Sent: Monday, September 30, 2024 4:03:15 PM Subject: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso < steffen at sdaoden.eu > wrote noone ever told them that even the eldest C can be used in a safe way; Perhaps we have different meanings of the word safe. void foo(char *p) { /* interesting stuff here */ ; free(p); } void bar() { char *p = malloc(20); foo(p); printf("foo is %s\n", p); foo(p); } Why should I have to think about this code when the language already knows what is wrong. No one would make the claim that programming in machine "language" is safe. No one would make the claim that programming in assembly "language" is safe. I've always viewed C as a portable assembler. I think the real issue has nothing to do with the "safety" of C, but rather the "safety" of your-choice-of-C-libraries-and-methods. My $.02 Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Tue Oct 1 14:31:38 2024 From: coff at tuhs.org (Warren Toomey via COFF) Date: Tue, 1 Oct 2024 14:31:38 +1000 Subject: [COFF] Fwd: Re: Trove of CSTR's Message-ID: Poul-Henning also suggests this link as well ... Warren ----- Forwarded message from Poul-Henning Kamp ----- There is also 3B stuff in various other subdirectories on that site, for instance: https://www.telecomarchive.com/six-digit.html ----- End forwarded message ----- From ralph at inputplus.co.uk Tue Oct 1 21:52:36 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 01 Oct 2024 12:52:36 +0100 Subject: [COFF] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930175949.GI17434@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180559.GF9067@mcvoy.com> <20240930175949.GI17434@mcvoy.com> Message-ID: <20241001115236.D5993207D9@orac.inputplus.co.uk> Hi Larry, > > You can't have your missle defense software pause to do garbage > > collection when you're trying to shoot down an incoming ballistic > > missile. > > That's why I like reference counting. It doesn't have the long pauses > that other garbage collection systems have, when the variable goes out > of scope, you decrement, last guy frees. Seems pretty simple. It's better, but the free() might cause a varying amount of work, say due to coallescing. Garbage collection these days doesn't have to be long-pause ‘stop the world’. Go's GC thread runs concurrently with the others, for example. https://tip.golang.org/doc/gc-guide -- Cheers, Ralph. From ralph at inputplus.co.uk Tue Oct 1 23:20:59 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 01 Oct 2024 14:20:59 +0100 Subject: [COFF] Shadowing variables in Go. In-Reply-To: <202410011243.491ChKiV419651@freefriends.org> References: <20240930003630.GE17434@mcvoy.com> <202410011243.491ChKiV419651@freefriends.org> Message-ID: <20241001132059.511CD1FB21@orac.inputplus.co.uk> Taken to COFF... Hi Arnold, > In main(), I *think* I'm assigning to the global clientSet so that > I can use it later. But because of the 'err' and the :=, I've > actually created a local variable that shadows the global one, and in > otherfunc(), the global clientSet is still nil. Kaboom! > > The correct way to write the code is: > > var err error > clientSet, err = cluster.MakeClient() // or whatever I think this is a common problem when learning Go, like assigning getchar()'s value to a char in C. It was back in ’14 anyway, when I saw https://www.qureet.com/blog/golang-beartrap/ which has an ‘err’ at an outer scope be unwritten by the ‘:=’ with the new, assigned-to ‘err’ going un-checked. The author mentions ‘go vet’ highlights these cases with -shadow, which is off by default. https://pkg.go.dev/github.com/golangci/govet#hdr-Shadowed_variables suggests that's still the case. -- Cheers, Ralph. From stuff at riddermarkfarm.ca Wed Oct 2 01:08:06 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Tue, 1 Oct 2024 11:08:06 -0400 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: [-->COFF] On 2024-10-01 10:56, Dan Cross wrote (in part): > I've found a grounding in mathematics useful for programming, but > beyond some knowledge of the physical constraints that the universe > places on us and a very healthy appreciation for the scientific > method, I'm having a hard time understanding how the hard sciences > would help out too much. Electrical engineering seems like it would be > more useful, than, say, chemistry or geology. I see this as related to the old question about whether it is easier to teach domain experts to program or teach programmers about the domain. (I worked for a company that wrote/sold scientific libraries for embedded systems.) We had a mixture but the former was often easier. S. > > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. > > - Dan C. From paul.winalski at gmail.com Wed Oct 2 02:40:32 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 1 Oct 2024 12:40:32 -0400 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011313.491DD4ac421643@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: On Tue, Oct 1, 2024 at 9:13 AM wrote: > This goes back to the evolution thing. At the time, C was a huge > step up from FORTRAN and assembly. > Certainly it's a step up (and a BIG step up) from assembly. But I'd say C is a step sidewise from Fortran. An awful lot of HPTC programming involves throwing multidimensional arrays around and C is not suitable for that. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Oct 2 02:49:10 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 1 Oct 2024 12:49:10 -0400 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011347.491DlAsJ423777@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> Message-ID: On Tue, Oct 1, 2024 at 10:07 AM wrote: [regarding writing an Ada compiler as a class project] > Did you do generics? That and the run time, which had some real-time > bits to it (*IIRC*, it's been a long time), as well as the cross > object code type checking, would have been real bears. > > Like many things, the first 90% is easy, the second 90% is hard. :-) > > I was in DEC's compiler group when they were implementing Ada for VAX/VMS. It gets very tricky when routine libraries are involved. Just figuring out the compilation order can be a real bear (part of this is the cross object code type checking you mention). >From my viewpoint Ada suffered two problems. First, it was such a large language and very tricky to implement--even more so than PL/I. Second, it had US Government cooties. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Wed Oct 2 03:09:27 2024 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 01 Oct 2024 18:09:27 +0100 Subject: [COFF] C a step up from Fortran. In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: <20241001170927.4C66F1FB21@orac.inputplus.co.uk> Hi Paul, > Arnold wrote: > > This goes back to the evolution thing. At the time, C was a huge > > step up from FORTRAN and assembly. > > Certainly it's a step up (and a BIG step up) from assembly. > But I'd say C is a step sidewise from Fortran. An awful lot of HPTC > programming involves throwing multidimensional arrays around and C is > not suitable for that. I expect the structured-programming parts of C were being referred to as a step up compared to Fortran 77. Ratfor was a step up in the same direction. Don't disagree about the HPTC side. -- Cheers, Ralph. From arnold at skeeve.com Wed Oct 2 05:08:49 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 13:08:49 -0600 Subject: [COFF] [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: <202410011908.491J8nM9448504@freefriends.org> Paul Winalski wrote: > On Tue, Oct 1, 2024 at 9:13 AM wrote: > > > This goes back to the evolution thing. At the time, C was a huge > > step up from FORTRAN and assembly. > > > > Certainly it's a step up (and a BIG step up) from assembly. But I'd say C > is a step sidewise from Fortran. An awful lot of HPTC programming involves > throwing multidimensional arrays around and C is not suitable for that. > > -Paul W. In my head, FORTRAN is still FORTRAN 66, where there are no while loops, or else statements, and the only data structure is the array. For non-HPC stuff, C was a huge step up.