I don't know that structure copying breaks any complexity or bounds on execution time rules. Many compilers may be different, but in the generated code I've seen, when you pass in a structure to a function, the receiving function copies it to the stack. In the portable C compiler, when you return a structure as a result, it is first copied to a static area, a pointer to that area is returned, then the caller copies that out to wherever it's meant to go, either a variable that's being assigned (which could be on the stack or elsewhere), or to a place on the stack that was reserved for it because that result will now be an argument to another function to be called. So there's some copying, but that's proportional to the size of the structure, it's linear, and there's no dynamic memory allocation going on. On 09/28/2024 09:58 AM, G. Branden Robinson wrote:

Hi Luther, At 2024-09-28T10:47:44-0700, Luther Johnson wrote: I have no problem with this presentation, but recall the principle--the tenet--that Doug was upholding: Even without dynamic memory allocation, if you did something linear, something O(n), it was a lose and a violation of the tenet. I can easily see the appeal of a language whose every operation really is O(1). Once upon a time, a university course, or equivalent experience, in assembly language (on a CLEAN instruction set, not x86) is what taught you the virtues and drawbacks of thinking about and implementing things that way. But my view is that C hasn't been one of those languages for a very long time, since before its initial ANSI standardization at the latest. At 2024-09-28T10:52:16-0700, Luther Johnson wrote: It's my understanding that the ability to work with structs as first-class citizens in function calls, as parameters _or_ return types, was something fairly late to stabilize in C compilers. Second-hand, I gather that pre-standard C as told by K&R explicitly did _not_ countenance this. So a lot of early C code, including that in libraries, indirected nearly all struct access, even when read-only, through pointers. This is often a win, but not always. A few minutes ago I shot off my mouth to this list about how much better the standard library design could have been if the return of structs by value had been supported much earlier. Our industry has, it seemss, been slow to appreciate the distinction between what C++ eventually came to explicitly call "copy" semantics and "move" semantics. Rust's paradigmatic dedication to the concept of data "ownership" at last seems to be popularizing the practice of thinking about these things. (For my part, I will forever hurl calumnies at computer architects who refer to copy operations as "MOV" or similar. If the operation doesn't destroy the source, it's not a move--I don't care how many thousands of pages of manuals Intel writes saying otherwise. Even the RISC-V specs screw this up, I assume in a deliberate but embarrassing attempt to win mindshare among x86 programmers who cling to this myth as they do so many others.) For a moment I considered giving credit to a virtuous few '80s C programmers who recognized that there was indeed no need to copy a struct upon passing it to a function if you knew the callee wasn't going to modify that struct...but we had a way of saying this, "const", and library writers of that era were infamously indifferent to using "const" in their APIs where it would have done good. So, no, no credit. Here's a paragraph from a 1987 text I wish I'd read back then, or at any time before being exposed to C. "[Language] does not define how parameter passing is implemented. A program is erroneous if it depends on a specific implementation method. The two obvious implementations are by copy and by reference. With an implementation that copies parameters, an `out` or `in out` actual parameter will not be updated until (normal) return from the subprogram. Therefore if the subprogram propagates an exception, the actual parameter will be unchanged. This is clearly not the case when a reference implementation is used. The difficulty with this vagueness in the definition of [language] is that it is quite awkward to be sure that a program is independent of the implementation method. (You might wonder why the language does not define the implementation method. The reason is that the copy mechanism is very inefficient with large parameters, whereas the reference mechanism is prohibitively expensive on distributed systems.)"[1] I admire the frankness. It points the way forward to reasoned discussion of engineering tradeoffs, as opposed to programming language boosterism. (By contrast, the trashing of boosters and their rhetoric is an obvious service to humanity. See? I'm charitable!) I concealed the name of the programming language because people have a tendency to unfairly disregard and denigrate it in spite of (or because of?) its many excellent properties and suitability for robust and reliable systems, in contrast to slovenly prototypes that minimize launch costs and impose negative externalities on users (and on anyone unlucky enough to be stuck supporting them). But then again cowboy programmers and their managers likely don't read my drivel anyway. They're busy chasing AI money before the bubble bursts. Anyway--the language is Ada. Regards, Branden [1] Watt, Wichmann, Findlay. _Ada Language and Methodology_. Prentice-Hall, 1987, p. 395.

G. Branden, I get it. From your and Doug's responses, even O(n) baked-in costs can be a problem. On 09/28/2024 03:08 PM, Luther Johnson wrote:

for a while, every instruction has [sic] an exactly predictable and

count. ...[Then] all of a sudden you had instructions with O(n) cycle

> spinelessly buckled to allow malloc(0) to return 0, as some > implementations gratuitously did.

What was the alternative? There was no such thing as an exception, and if a pointer was an int and an int was as wide as a machine address, there'd be no way to indicate failure in-band, either.

How does malloc(0) get this job done and what benefit does it bring?

Just responding to random things that I noticed: You don't need special syntax for tail-call. It should be done transparently when a call is the last thing that gets executed. Special syntax will merely allow confused people to use it in the wrong place and get confused more. malloc(0) should return a unique ptr. So that "T* a = malloc(0); T* b = malloc(0); a != (T*)0 && a != b". Without this, malloc(0) acts differently from malloc(n) for n > 0. Note that except for arrays, function arguments & result are copied so copying a struct makes perfect sense. Passing arrays by reference may have been due to residual Fortran influence! [Just guessing] Also note: that one exception has been the cause of many problems. In any case you have not argued convincingly about why dynamic memory allocation should be in the language (runtime) :-) And adding that wouldn't have fixed any of the existing problems with the language. Bakul g.branden.robinson(a)gmail.com> wrote:

I wrote a letter to the ANSI C (1989) committee. Please allow malloc(0). Please allow zero-length arrays. I got two letters back, saying that malloc(0) is illegal because zero-length arrays are illegal, and the other vice versa. I fumed.

On Sun, Sep 29, 2024 at 8:08 AM Douglas McIlroy < douglas.mcilroy(a)dartmouth.edu&gt; wrote: > I have to concede Branden's "gotcha". Struct copying is definitely not > O(1). > > A real-life hazard of non-O(1) operations. Vic Vyssotsky put bzero (I > forget what Vic called it) into Fortran II. Sometime later, he found that a > percolation simulation was running annoyingly slowly. It took some study to > discover that the real inner loop of the program was not the percolation, > which touched only a small fraction of a 2D field. More time went into the > innocuous bzero initializer. The fix was to ADD code to the inner loop to > remember what entries had been touched, and initialize only those for the > next round of the simulation. > > > for a while, every instruction has [sic] an exactly predictable and > constant cycle > > count. ...[Then] all of a sudden you had instructions with O(n) cycle > counts. > > O(n) cycle counts were nothing new. In the 1950s we had the IBM 1620 > with arbitrary-length arithmetic and the 709 with "convert" instructions > whose cycle count went up to 256. > > >> spinelessly buckled to allow malloc(0) to return 0, as some > >> implementations gratuitously did. > > > What was the alternative? There was no such thing as an exception, and > > if a pointer was an int and an int was as wide as a machine address, > > there'd be no way to indicate failure in-band, either. > > What makes you think allocating zero space should fail? If the size n of > a set is determined at run time, why should one have to special-case its > space allocation when n=0? Subsequent processing of the form for(i=0; i<n; > i++) {...} will handle it gracefully with no special code. Malloc should do > as it did in v7--return a non-null pointer different from any other active > malloc pointer, as Bakul stated. If worse comes to worst[1] this can be > done by padding up to the next feasible size. Regardless of how the pointer > is created, any access via it would of course be out of bounds and hence > wrong. > > > How does malloc(0) get this job done and what benefit does it bring? > > If I understand the "job" (about initializing structure members) > correctly, malloc(0) has no bearing on it. The benefit lies elsewhere. > > Apropos of tail calls, Rob Pike had a nice name for an explicit tail > call, "become". It's certainly reasonable, though, to make compilers > recognize tail calls implicitly. > > [1] Worse didn't come to worst in the original malloc. It attached > metadata to each block, so even blocks of size zero consumed some memory. > > Doug > > On Sat, Sep 28, 2024 at 1:59 PM Bakul Shah via TUHS &lt;tuhs(a)tuhs.org&gt; > wrote: > >> Just responding to random things that I noticed: >> >> You don't need special syntax for tail-call. It should be done >> transparently when a call is the last thing that gets executed. Special >> syntax will merely allow confused people to use it in the wrong place and >> get confused more. >> >> malloc(0) should return a unique ptr. So that "T* a = malloc(0); T* b = >> malloc(0); a != (T*)0 && a != b". Without this, malloc(0) acts differently >> from malloc(n) for n > 0. >> >> Note that except for arrays, function arguments & result are copied so >> copying a struct makes perfect sense. Passing arrays by reference may have >> been due to residual Fortran influence! [Just guessing] Also note: that one >> exception has been the cause of many problems. >> >> In any case you have not argued convincingly about why dynamic memory >> allocation should be in the language (runtime) :-) And adding that wouldn't >> have fixed any of the existing problems with the language. >> >> Bakul >> >> > On Sep 28, 2024, at 9:58 AM, G. Branden Robinson < >> g.branden.robinson(a)gmail.com&gt; wrote: >> > >> > At 2024-09-28T09:34:14-0400, Douglas McIlroy wrote: >> >>> C's refusal to specify dynamic memory allocation in the language >> >>> runtime (as opposed to, eventually, the standard library) >> >> >> >> This complaint overlooks one tenet of C: every operation in what you >> >> call "language runtime" takes O(1) time. Dynamic memory allocation >> >> is not such an operation. >> > >> > A fair point. Let me argue about it anyway. ;-) >> > >> > I'd make three observations. First, K&R did _not_ tout this in their >> > book presenting ANSI C. I went back and checked the prefaces, >> > introduction, and the section presenting a simple malloc()/free() >> > implementation. The tenet you claim for the language is not explicitly >> > articulated and, if I squint really hard, I can only barely perceive >> > (imagine?) it deeply between the lines in some of the prefatory >> material >> > to which K&R mostly confine their efforts to promote the language. In >> > my view, a "tenet" is something more overt: the sort of thing U.S. >> > politicians try to get hung on the walls of every public school >> > classroom, like Henry Spencer's Ten Commandments of C[1] (which itself >> > does not mention this "core language has only O(1) features" >> principle). >> > >> > Second, in reviewing K&R I was reminded that structure copying is part >> > of the language. ("There are no operations that manipulate an entire >> > array or string, although structures may be copied as a unit."[2]) >> > Doesn't that break the tenet right there? >> > >> > Third, and following on from the foregoing, your point reminded me of >> my >> > youth programming non-pipelined machines with no caches. You could set >> > your watch by (just about) any instruction in the set--and often did, >> > because we penurious microcomputer guys often lacked hardware real-time >> > clocks, too. That is to say, for a while, every instruction has an >> > exactly predictable and constant cycle count. (The _value_ of that >> > constant might depend on the addressing mode, because that would have >> > consequences on memory fetches, but the principle stood.) When the Z80 >> > extended the 8080's instruction set, they ate from Tree of Knowledge >> > with block-copy instructions like LDIR and LDDR, and all of a sudden >> you >> > had instructions with O(n) cycle counts. But as a rule, programmers >> > seemed to welcome this instead of recognizing it as knowing sin, >> because >> > you generally knew worst-case how many bytes you'd be copying and take >> > that into account. (The worst worst case was a mere 64kB!) >> > >> > Further, Z80 home computers in low-end configurations (that is, no disk >> > drives) often did a shocking thing: they ran with all interrupts >> masked. >> > All the time. The one non-maskable interrupt was RESET, after which >> you >> > weren't going to be resuming execution of your program anyway. Not >> from >> > the same instruction, at least. As I recall the TRS-80 Model I/III/4 >> > didn't even have logic on the motherboard to decode the Z80's >> "interrupt >> > mode 2", which was vectored, I think. Even in the "high-end" >> > configurations of these tiny machines, you got a whopping ONE interrupt >> > to play with ("IM 1"). >> > >> > Later, when the Hitachi 6309 smuggled similar block-transfer decadence >> > into its extensions to the Motorola 6809 (to the excitement of we >> > semi-consciously Unix-adjacent OS-9 users) they faced a starker >> problem, >> > because the 6809 didn't wall off interrupts in the same way the 8080 >> and >> > Z80. They therefore presented the programmer with the novelty of the >> > restartable instruction, and a new generation of programmers became >> > acquainted with the hard lessons time-sharing minicomputer people were >> > familiar with. >> > >> > My point in this digression is that, in my opinion, it's tough to hold >> > fast to the O(1) tenet you claim for C's core language and to another >> at >> > the same time: the language's identity as a "portable assembly >> > language". Unless every programmer has control over the compiler--and >> > they don't--you can't predict when the compiler will emit an O(n) block >> > transfer instruction. You'll just have to look at the disassembly. >> > >> > _Maybe_ you can retain purity by...never copying structs. I don't >> think >> > lint or any other tool ever checked for this. Your advocacy of this >> > tenet is the first time I've heard it presented. >> > >> > If you were to suggest to me that most of the time I've spent in my >> life >> > arguing with C advocates was with rotten exemplars of the species and >> > therefore was time wasted, I would concede the point. >> > >> > There's just so danged _many_ of them... >> > >> >> Your hobbyhorse awakened one of mine. >> >> >> >> malloc was in v7, before the C standard was written. The standard >> >> spinelessly buckled to allow malloc(0) to return 0, as some >> >> implementations gratuitously did. >> > >> > What was the alternative? There was no such thing as an exception, and >> > if a pointer was an int and an int was as wide as a machine address, >> > there'd be no way to indicate failure in-band, either. >> > >> > If the choice was that or another instance of atoi()'s wincingly awful >> > "does this 0 represent an error or successful conversion of a zero >> > input?" land mine, ANSI might have made the right choice. >> > >> >> I can't imagine that any program ever actually wanted the feature. Now >> >> it's one more undefined behavior that lurks in thousands of programs. >> > >> > Hoare admitted to only one billion-dollar mistake. No one dares count >> > how many to write in C's ledger. This was predicted, wasn't it? >> > Everyone loved C because it was fast: it was performant, because it >> > never met a runtime check it didn't eschew--recall again Kernighan >> > punking Pascal on this exact point--and it was quick for the programmer >> > to write because it never met a _compile_-time check it didn't eschew. >> > C was born as a language for wizards who never made mistakes. >> > >> > The problem is that, like James Madison's fictive government of angels, >> > such entities don't exist. The staff of the CSRC itself may have been >> > overwhelmingly populated with frank, modest, and self-deprecating >> > people--and I'll emphasize here that I'm aware of no accounts that this >> > is anything but true--but C unfortunately played a part in stoking a >> > culture of pretension among software developers. "C is a language in >> > which wizards program. I program in C. Therefore I'm a wizard." is >> how >> > the syllogism (spot the fallacy) went. I don't know who does more >> > damage--the people who believe their own BS, or the ones who know >> > they're scamming their colleagues. >> > >> >> There are two arguments for malloc(0), Most importantly, it caters for >> >> a limiting case for aggregates generated at runtime--an instance of >> >> Kernighan's Law, "Do nothing gracefully". It also provides a way to >> >> create a distinctive pointer to impart some meta-information, e.g. >> >> "TBD" or "end of subgroup", distinct from the null pointer, which >> >> merely denotes absence. >> > >> > I think I might be confused now. I've frequently seen arrays of >> structs >> > initialized from lists of literals ending in a series of "NULL" >> > structure members, in code that antedates or ignores C99's wonderful >> > feature of designated initializers for aggregate types.[3] How does >> > malloc(0) get this job done and what benefit does it bring? >> > >> > Last time I posted to TUHS I mentioned a proposal for explicit >> tail-call >> > elimination in C. I got the syntax wrong. The proposal was "return >> > goto;". The WG14 document number is N2920 and it's by Alex Gilding. >> > Good stuff.[4] I hope we see it in C2y. >> > >> > Predictably, I must confess that I didn't make much headway on >> > Schiller's 1975 "secure kernel" paper. Maybe next time. >> > >> > Regards, >> > Branden >> > >> > [1] https://web.cs.dal.ca/~jamie/UWO/C/the10fromHenryS.html >> > >> > I can easily imagine that the tenet held at _some_ point in the >> > C's history. It's _got_ to be the reason that the language >> > relegates memset() and memcpy() to the standard library (or to the >> > programmer's own devise)! :-O >> > >> > [2] Kernighan & Ritchie, _The C Programming Language_, 2nd edition, p. >> 2 >> > >> > Having thus admitted the camel's nose to the tent, K&R would have >> > done the world a major service by making memset(), or at least >> > bzero(), a language feature, the latter perhaps by having "= 0" >> > validly apply to an lvalue of non-primitive type. Okay, >> > _potentially_ a major service. You'd still need the self-regarding >> > wizard programmers to bother coding it, which they wouldn't in many >> > cases "because speed". Move fast, break stuff. >> > >> > C++ screwed this up too, and stubbornly stuck by it for a long time. >> > >> > https://cplusplus.github.io/CWG/issues/178.html >> > >> > [3] https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html >> > [4] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2920.pdf >> >>

Hi Werner, malloc(0) isn't undefined behaviour but implementation defined.

return NULL?

-- Cheers, Ralph.

On Sat, Sep 28, 2024, 5:05 PM Rob Pike &lt;robpike(a)gmail.com&gt; wrote: And now we have zero length arrays an UB malloc(0).

[ screed omitted ]

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

I ran a company that developed a product that was orders of magnitude more complex than the v7 kernel (low bar but still) all in C and we had *NONE* of those supposed problems. We were careful to use stuff that worked, I'm "famous" in that company as the guy was viewed as "that was invented after 1980 so Larry won't let us use it". Not true, we used mmap and used POSIX signals, but mostly true. If you stick to the basics, C just works. And is portable, we supported every Unix (even SCO), MacOS, Windows, and all the Linux variants from ARM to IBM mainframes.

All that said, I get it, you want guard rails. You are not wrong, the caliber of programmers these days are nowhere near Bell Labs or Sun or my guys.

On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold(a)skeeve.com wrote: Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. It was the compilers course (701) and the really hard compilers course (702) at the time. The first course was to write a compiler for a subset of Ada and the second on increased the subset to be almost complete. We were supposed to do it on an IBM mainframe because the professor had his own version of lex/yacc there. Rob had a 3b1 and asked if we could do it there if he rewrote the parser stuff. Prof said sure. In one semester we had a compiler, no optimizer and not much in the way of graceful error handling, but it compiled stuff that ran. We did all of Ada other than late binding of variables (I think that was Ada's templates) and threads and probably some other stuff I don't remember.

I don't consider myself to be that good of a programmer, I can point to dozens of people my age that can run circles around me and I'm sure there are many more.

But apparently the bar is pretty low these days and I agree, that's sad.

None of those ring a bell so I guess we did the easy stuff :-(

Funny, I've come to the same conclusion, both in programming and my retirement hobby. There is always someone way better than me, but you are correct, that doesn't mean I'm awful. Just have more to learn.

As a guy in his 2nd retirement (1st didn't stick) I can tell you I am so happy not having to deal with work stuff. My buddies who are still working tell me stories I find difficult to believe. They all say I'm so politically incorrect that I wouldn't last a week in today's world. If their stories are true, yeah, that's not for me. Weird politics and crappy programmers, count me out.

I think because the of the orders of magnitude increase in the demand for programmers, we now have a very large number of programmers with little or no math and science (and computer science doesn't count in the point I'm trying to make here, if that's your only science, you're not going to have the models in your head from other disciplines to give you useful analogs) background, and that's a big change from 40 years ago. So that has had an effect on who is programming, how they think about it, and how languages have been marketed to that programming audience. IMHO.

On Tue, Oct 1, 2024 at 10:32???AM Luther Johnson &lt;luther.johnson(a)makerlisp.com&gt; wrote: 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 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.

Each generation bemoans the qualities of following generations. (Perhaps justifiably in this case, but we're acting out a stereotyped pattern.) Having a mental model of a computer is a good idea, but I'd rather not have to teach the details of PDP-11 condition codes (which changed in unexpected ways over time) Now caches loom large, and should such a course provide a mental model of smart phones? [I think it should, and the course should cover secure boot, but that leaves lots less time for assembly language.] On Tue, Oct 1, 2024 at 11:20 AM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: the not you ago. audience. IMHO. http://www.mcvoy.com/lm/boat

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.

Sounds like boomer mentality... Kids these days... :-) Also sounds like the kind of arguments assembly language programmers presented when *we* were the "kids" trying out "structured programming"!

Rik Farrow &lt;rik(a)rikfarrow.com&gt; wrote: Also true. In the late 80s I was a sysadmin at Emory U. We had a Vax connected to BITNET with funky hardware and UREP, the Unix RSCS Emulation Program, from the University of Pennsylvania. Every time I had to dive into that code, I felt like I needed a shower afterwards. :-)

On Wed, Oct 2, 2024 at 2:27 AM &lt;arnold(a)skeeve.com&gt; wrote: Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I must point out that UREP wasn't from the University of Pennsylvania, but rather, from The Pennsylvania State University (yes, "The" is part of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State (psu.edu) is a state school in University Park, which is next to State College (really, that's the name of the town) with satellite campuses scattered around the state. - Dan C.

I do wonder if a version of it has survived somewhere; I've personally never seen it, but there's very little information about it out there anymore.

The problem is that, like James Madison's fictive government of angels, such entities don't exist. The staff of the CSRC itself may have been overwhelmingly populated with frank, modest, and self-deprecating people--and I'll emphasize here that I'm aware of no accounts that this is anything but true--but C unfortunately played a part in stoking a culture of pretension among software developers. "C is a language in which wizards program. I program in C. Therefore I'm a wizard." is how the syllogism (spot the fallacy) went. I don't know who does more damage--the people who believe their own BS, or the ones who know they're scamming their colleagues.