On Fri, Feb 28, 2025, 7:11 PM Dan Cross <crossd(a)gmail.com> wrote: Yea. It's reason to exist is for LinuxBoot scripting, though lots of other uses are possible. I know it from LinuxBoot... uutils is a Rust reimplementation of most of the GNU coreutils tools, Correct. Rust uses it's own library for system calls. This is a never ending series of problems for FreeBSD since the C API sometimes differs slightly with what's passed to the kernel and those seemingly trivial differences cause bugs. Also, new system calls can take a while (years) to appear. FreeBSD moved inodes to 64 bits 10 years ago and it was only in the last years that rust stopped using the old 32bit inode system calls. Warner - Dan C.

On Sat, Mar 01, 2025 at 02:01:11PM -0800, Larry McVoy wrote: The funny thing was that somewhere around then Sun Labs was paying Micheal Tiemann to make g++ work. With a deal that let him retain the rights to the code. I never understood that, one hand wants to charge for cc and the other hand is paying for free g++? The ways of Sun could be strange.

At 2025-03-01T20:07:42-0600, G. Branden Robinson wrote: I forgot to mention some support for this argument. I quote Bjarne Stroustrup in the 4th edition of his central C++ book. "Clearly, the 1998 language was far superior in features and in particular the detail of specification to the 1989 language. However, not all changes were improvements. In addition to the inevitable minor mistakes, two major features were added that should not have been: * Exception specifications provide run-time enforcement of which exceptions a function is allowed to throw. They were added at the energetic initiative of people from Sun Microsystems. Exception specifications turned out to be worse than useless for improving readability, reliability, and performance. They are deprecated (scheduled for removal) in the 2011 standard. ..." (p. 26) Regards, Branden

On Sat, Mar 01, 2025 at 08:07:37PM -0600, G. Branden Robinson wrote: As an engineer who was paid to try and convince Sun's execs that the pivot to Solaris/System V was a mistake, I have a different take. The 6 months I spent at the top of PAL-1 where McNealy & Co worked were unsuccessful but very educational. Hanging out there gave me insight into what all those execs did. It's very different from what an engineer does, we figure stuff out to the Nth degree. The execs did not have that luxury. What they did all day, every day, is make decisions about what to do but with only about 1/10th the amount of information an engineer would have. They simply couldn't wait long enough to know everything they wanted to know, the rest of the industry would pass them by. I would HATE to have their job. As I grew to understand their jobs, my respect for them went up but there is no amount of money that would make me want that job.

On Sat, Mar 1, 2025 at 5:01 PM Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon(a)orthanc.ca> wrote: I believe that was in the shift to Solaris, aka SunOS 5.x. As I recall, even the last versions of SunOS 4 came with a bundled compiler (though it was pre-ANSI, and probably PCC based). - Dan C.

On Sat, Mar 1, 2025 at 4:29 PM Clem Cole <clemc(a)ccc.com> wrote: Yes. I think so. But I also think that said C compiler wasn't adequate to bootstrap gcc or that there were extra steps / workarounds needed to do that. This was during the K&R -> ANSI cutover that Sun did this as well, and the old compiler was definitely K&R only. Yea, BLISS might have been better, but making the case it was $5k per CPU better was super hard. Warner On Sat, Mar 1, 2025 at 5:08 PM Dan Cross <crossd(a)gmail.com> wrote:

On Sat, Mar 1, 2025 at 4:47 PM Dan Cross <crossd(a)gmail.com> wrote: That may be what I'm recalling... you needed gmake, binutils, bison, flex and maybe a few others for sure... I also recall that 1.x was a lot harder to get going than 2.x on sparc. Yea, even gcc2 was a huge win. Yea. There comes a point where large swarms of adequate at a reasonable price is a better call than a few, more expensive things that get the job done in a smaller footprint of floor space or time (but higher cost). For a lot of things that crossover took place in the 2000-2010 time frame. Warner

On Sun, Mar 2, 2025 at 11:51 AM Doug McIntyre <merlyn(a)geeks.org> wrote: Huh. I totally believe you, but I have no memory of this. Perhaps I blanked it out; it does sound rather traumatic. - Dan C.

On 3/1/2025 5:46 PM, segaloco via TUHS wrote: For all our faults in the AIX team and IBM in general, there was no desire to have legacy IBM languages as primary in AIX. https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beg… tries to explain why PL.8 code existed in early AIX and how PL.8 code was eliminated in AIX 3 development. AIX for the RT 1&2 bundled pcc (with the HCR optimization phase in AIX 2). Since I left IBM in the midst of AIX 3 development, I'm not certain what happened with compilers after I left. Part of the confusion was IBM Toronto rewriting the Yorktown Research compiler to be a "product worthy" C compiler. There may have been desire to gain revenue for the Toronto compiler, but I assume that some some C compiler was bundled in AIX 3. Charlie -- voice: +1.512.784.7526 e-mail: sauer(a)technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer

On 2025-03-01 21:43, Dan Cross wrote: Some decades ago, I was checking whether our product ran properly on AIX (version forgotten). The xlc man page stated that at the highest optimisation level, the "semantics of the source code might not be respected" (or something very similar). I no longer remember the versions. Has anyone else seen this? S.

The N40 CD media may have included the compiler, but it also included a lot of other unbundled software features (e.g. AIXwindows, fax support, LocalTalk, WABI), so I don’t think this should be the benchmark. I’ve personally catalogged many sets of AIX 3 install tapes with only the various language runtime(s), and no compiler present. The tapes were generated for each customer and included only the features that were ordered. ok bear.

On 3/1/25 6:46 PM, Peter Yardley wrote: I've seen hints of this in Gentoo Stage 1 installs. Use existing tools to build Gentoo versions of the tools. Then use the Gentoo version of the tools to re-build the Gentoo version of the tools. Then do an empty tree rebuild of everything using the Gentoo version of the tools. -- Grant. . . .

On 3/1/25 3:38 PM, Larry McVoy wrote: Time has fogged the memories but I'll try. As has been noted, SunOS 4.x continued to ship a cc sufficient to build the kernel but which didn't otherwise track the language evolution going on. The unbundled tools were introduced to deliver those and, in a theory about the value of software, to earn the necessary investments by generating a return. It wasn't just marketing being revenue vampires though it presented an opportunity for feeding. There was a good bit of investment / change in the tools in this period. The SVR4 work brought the ANSI C front end from AT&T, FORTRAN technology purchases/licenses occurred, there was something going on with Pascal that I don't recall at the moment. Some of the investment was necessitated by the shift to SPARC and the demands that RISC posed on the code generation software. The appeal that these things must be done because they're necessary to have good and credible products was countered with a business sentiment that the value should manifest as a return visible in $. So I recall it as more textured than just "let's squeeze some $'s" but especially if you have the view that "C is part of the system" it's an affront. On 3/1/25 5:17 PM, Larry McVoy wrote: One of Sun's charms was a "let many flowers bloom, even if they contradict themselves" kind of culture. Sometimes this yielded successes and opportunities. Sometimes it resulted in frictions and periodic culls. (The "all the wood behind one arrow" SPARC focus was one such consequence, when the array of 68K, 386, and SPARC products got too logistically cacophonous and Sun blew a revenue projection in [I think] the last FY1989 quarter. The cacophony wasn't in engineering so much as the rest of the business: sales forecasting, manufacturing, support, ISV relationships. etc.) "Many flowers bloom" thinking wasn't restricted to just technology and extended to business models. The thinking that "investments should follow the revenue" visible in the tools unbundling along with additional influences led to the "planets" reorganization of Sun (e.g., SunSoft, SunPro, etc.) where inter-unit pricing and therefore revenues would demonstrate where value was derived. Sun's R&D levels were always higher than conventional business wisdom said they should be so rationalizing them drove such thinking. Whatever the merits of the planets model in theory were, they were completely lost in the execution. The implementation looked more like the State Planning Committee of the Soviet Union than Wall Street. The company focused inward rather than outward to the market for a while before the whole thing was relaxed back to something more "normal". Definitely one of the worst self-inflicted wounds in the company's history. IMO, such failures emerged from the same environment that permitted the exploration of unusual ideas and the taking of big swings. Sun was probably better off and certainly more impactful, fun, and interesting for being that way even at the cost of some dramatic face plants.

Rob Gingell wrote: KCC, started by Kok Chen at the Stanford AI lab. Probably Jay Lepreau's PCC from Utah, or maybe Sargasso C.

On 3/4/25 4:55 PM, Rob Gingell wrote: This would have been 1991-1992, so we were working on mostly 4.3 BSD (me) and SunOS (Brian). We didn't expect more than K&R from the compiler, even though we were primarily using gcc. It was before autoconf, so we rolled our own version to create a `sysdefs.h', and had code to choose between POSIX, USG, and BSD versions of functions. I don't think it would have compiled on anything older than possibly 4.2 BSD, and probably not that, so I think your speculation about the post-V7 runtime support is on the mark. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

On 3/5/25 9:26 AM, Henry Bent wrote: Nice! I haven't done much software archaeology like that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

Please! At the very least, can you put the code online?

On Mar 1, 2025, at 6:16 PM, Larry McVoy <lm(a)mcvoy.com> wrote: There are quite a few newer languages but none outstanding (IMHO). I do like V but that may be because I haven't written enough code in it! AFAIK all such attempts have failed. C is a great portable assembler but not so great as a high level language. I looked at it when it was mentioned in the past. Didn't like it enough. Anyway, my main point was that please do something innovative and interesting if you must use a new HLL for an OS!

On Mar 1, 2025, at 7:16 PM, Larry McVoy <lm(a)mcvoy.com> wrote: My comment was about innovation in the OS, not about any HLL. Sure. C's Achilles' heel is its type system. No extension can paper over that. Once you fix that it is no longer C. Newer languages can in fact be seen as fixing/adding things like proper strings, default read/write rules, memory allocation rules, modules/packages, object/closures, etc. over C. This is why I said they are not particularly outstanding. A lot of it seems rather adhoc.

At 2025-03-02T17:54:01+0000, segaloco via TUHS wrote: If I'm understanding Bakul's point correctly, then what you're saying is a defensible claim about many aspects of C but emphatically _not_ of its type system. The language does _not_ give you the tools to implement a rigorous type system as, Haskell programmers or type theorists would conceive of it. I mean, you could write a Haskell compiler in C, but you wouldn't be able to apply its type logic to C's own type system. (Maybe you could do it for any types other than the primitive ones already supported, with sufficient abuse of the preprocessor.) This rigid inability was baked into C from day one. Everything that can possibly be represented in a machine register with all bits clear shows up as an integral zero literal. '\0' == 0 == nullptr == struct { } == union { } The CSRC staked a lot on the typeless B, and clung to that heritage. I don't think it's an accident that C's designers expressed type _aliasing_ with the keyword "typedef". Types simply were not taken seriously as reasoning tools. C was a language for people who wanted to get that crap out of the way so they could think about binary representations. (Okay, octal.) C was aggressively oversold, I think more by by its fans than its designers. Even its reputation as "portable assembler" withstands scrutiny only as long as all you want to port to are models in the PDP-11 line. If you think that claim is crack-headed, review London & Reiser's paper on porting Unix to the VAX-11/780. Even setting aside the problems with nroff/troff and the Bourne shell, they pointed their fingers at problems that a "portable assembly language" would already have considered, like machines having differing alignment requirements, or having the standard I/O library's binary I/O functions write and interpret some kind of header in the file expressing basic facts like the endianness of various integer widths (big, little, or FP-11). Magic numbers were good enough for object file formats, but not applications programmers, I guess. I don't doubt that people could be massively more productive in C than in PDP-11 assembly language. But that claim doesn't establish anything that wasn't already known about the utility of higher-level languages. K&R were still trying to warn people in 1988 that C was not a hammer for all nails. "...C offers only straightforward, single-thread control flow: tests, loops, grouping, and subprograms, but not multiprogramming, parallel operations, synchronization, or coroutines." (_The C Programming Language, 2nd edition, p. 2) I guess we can add a general, flexible algebraic type system to the list of missing features. Regards, Branden

Problems I have with C as a systems language is there is no certainty about representation of a structure in memory and hence when it is written to disk. I will be happy to be corrected but I remember this behaviour to be compiler dependant. Other languages such as Bliss and to perhaps a lesser degree Pascal had implicit control of this. Having said that I worked with C as a systems language many times. .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley(a)gmail.com

A bit of a story. At SiCortex, we were well aware that structure layout and bitfields were compiler dependent, yet we had real requirements that high (?) level languages be able to directly interact with hardware defined structures. So there was a chip spec that was the master truth about register layouts and hardware structures. Wilson Snyder (of Verilator fame) wrote a postprocessor that swallowed the chip spec document and spit out header files in various languages, one of which was C Preprocessor compatible #defines for field offset, position, and width. We programmers were careful to always use GET and SET macros to access objects with hardware specified layouts. IIRC there were additional macros to make sure that hardware accesses always used the proper machine instructions and fences. I don’t think the use of these macros cost much or any performance because they mostly resolved into shifts and masks with constants. It’s too bad that that C doesn’t have standardized rules for structures, because even when hardware isn’t involved, one must be extremely careful with cacheline alignment of fields in order to get good performance. __attribute__((aligned(64)) for the win, but it is ugly. I don’t think there is even a portable way to get the cacheline size. Then there is compiler register promotion, and volatile. -L

On Mon, Mar 03, 2025 at 05:55:10PM +0000, segaloco via TUHS wrote: Alignment is your answer. Understand that and the confusion goes away: slovax ~/tmp cat pack.c #include <stdio.h> struct { char a; int b; } foo; int main(void) { printf("%lu\n", sizeof(foo)); return (0); } slovax ~/tmp cc pack.c slovax ~/tmp a.out 8 Even x86, it would appear, wants to do aligned loads. I'm a little surprised by that though maybe I shouldn't be as there is a RISC implemented by the microcode under the x86 CPU. Does anyone know if gcc has an option to ignore alignment and pack the structs?

Warner Losh wrote in &lt;CANCZdfrb7FLL_zhDq5E65kAzMsJ8HHBYJbcnWn+bhkAPUySKwg(a)mail.gmail.com&gt;: |On Mon, Mar 3, 2025, 11:28 AM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: |> On Mon, Mar 03, 2025 at 05:55:10PM +0000, segaloco via TUHS wrote: |>> Truth be told the subjectivity of implementing struct memory |> characteristics has |>> bewildered me more rather than less as time goes on. |> |> Alignment is your answer. Understand that and the confusion goes away: |> |> slovax ~/tmp cat pack.c |> #include <stdio.h> |> |> struct { |> char a; |> int b; |>} foo; |> |> int |> main(void) |> { |> printf("%lu\n", sizeof(foo)); |> return (0); |>} |> |> slovax ~/tmp cc pack.c |> slovax ~/tmp a.out |> 8 |> |> |> Even x86, it would appear, wants to do aligned loads. I'm a little |> surprised by that though maybe I shouldn't be as there is a RISC |> implemented by the microcode under the x86 CPU. |> |> Does anyone know if gcc has an option to ignore alignment and pack the |> structs? |> | |__attribute__ ((__packed__)) __attribute__((packed, aligned(1))) I have forgotten why both. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

On Mon, 3 Mar 2025, Larry McVoy wrote: Isn't it __attribute__((packed)) or something like that? -uso.

On Mon, Mar 3, 2025 at 1:28 PM Larry McVoy &lt;lm(a)mcvoy.com&gt; wrote: at the same speed as naturally aligned accesses. The worst case is an unaligned access that straddles a machine-word boundary. -Paul W.

On Mon, Mar 3, 2025, 10:00 AM Paul Winalski &lt;paul.winalski(a)gmail.com&gt; wrote: Sizeof(int) is compiler dependent. uint32_t even isn't always 4 bytes. There's no way to say "packed" that is portable. Endian isn't specified so you have to cope with that. And bit field order is different for big/little Endian compiler modes, but that detail is just super common. It isn't mandated. And pointers aren't valid run to run And that's even before you try to save a string... it's a mess that have a lot of solutions to serialize... Warner

At Mon, 3 Mar 2025 22:31:13 +1100, Peter Yardley &lt;peter.martin.yardley(a)gmail.com&gt; wrote: Subject: [TUHS] Re: Any UNIX With No C In Userland? That might be true for some nit-pick-ity "Standard C", but it isn't true for most real implementations, at least in the realm of 'hosted' implementations. Real implementations do after all have to interface with real hardware. In fact it's not impossible, or even really hard, to define a struct, even with bitfields, that can be "portably" compiled for a number of different architectures and platforms, including with different word sizes and endianness and which will map directly onto an external binary data representation. It can get a bit ugly to look at, but it works. Between the compiler manual and the ABI manual it _should_ all be quite clear how to do it. Of course "Standard C" has only got worse as it has morphed along the way, growing increasingly thorny with more instead of less "Undefined Behaviour". -- Greg A. Woods &lt;gwoods(a)acm.org&gt; Kelowna, BC +1 250 762-7675 RoboHack &lt;woods(a)robohack.ca&gt; Planix, Inc. &lt;woods(a)planix.com&gt; Avoncote Farms &lt;woods(a)avoncote.ca&gt;