Char is different. One of the silly foibles of C. char can be signed or unsigned at the implementation's decision. -----Original Message----- From: Steve Nickolas <usotsuki(a)buric.co> Sent: Friday, May 15, 2020 5:53 PM To: Richard Tobin <richard(a)inf.ed.ac.uk> Cc: Steve Nickolas <usotsuki(a)buric.co>; ron(a)ronnatalie.com; tuhs(a)tuhs.org Subject: Re: [TUHS] v7 K&R C Huh. I thought all integers were supposed to be signed by default regardless of their size. o.o That said, I do use "int c; ... c=fgetc(stdin);" or the like in my code. -uso.

On Sat, May 16, 2020 at 01:34:27AM +0200, Steffen Nurpmeso wrote: Yeah, I agree. UTF-8 is clever, really clever. It makes the other stuff look ham handed.

Ronald Natalie wrote in <5DB09C5A-F5DA-4375-AAA5-0711FC6FB1D9(a)ronnatalie.com>: |> On May 15, 2020, at 7:34 PM, Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote: |> ron(a)ronnatalie.com wrote in |> <077a01d62b08$e696bee0$b3c43ca0$(a)ronnatalie.com>: |>|Char is different. One of the silly foibles of C. char can be \ |>|signed or |>|unsigned at the implementation's decision. |> |> And i would wish Thompson and Pike would have felt the need to |> design UTF-8 ten years earlier. Maybe we would have a halfway |> usable "wide" character interface in the standard (C) library. |The issue is making char play double duty as a basic storage unit and \ |a native character. |This means you can never have 16 (or 32 bit) chars on any machine that \ |you wanted to support 8 bit integers. Oh, I am not the person to step in here. [I deleted 60+ lines of char*/void*, and typedefs, etc. experiences i had. And POSIX specifying that a byte has 8-bit. And soon that NULL/(void*)0 has all bits 0.] Unicode / ISO 10646 did not exist by then. sure. I am undecided. I was a real fan of UTF-32 (32-bit character) at times, but when i looked more deeply in Unicode, it turned out to be false thinking: some languages are so complex that you need to address entire sentences, or at least encapsulate "graphem" boundaries, going for "codepoints" is just wrong. Then i thought Microsoft and their UTF-16 decision was not that bad, because almost all real life characters of Unicode can nonetheless be addressed by a single 16-bit codepoint, and that eases programming. But moreover UTF-8 needs three bytes for most of them. Why did it happen? Why was the char type overloaded like this? Why was there no byte or "mem" type? It is to this day, i think, that ISO C allows to bypass their (terrible) aliasing rules by casting to and from char*. In v5 usr/src/s2/mail.c i see +getfield(buf) +char buf[]; +{ + int j; + char c; + + j = 0; + while((c = buf[j] = getc(iobuf)) >= 0) + if(c==':' || c=='\n') { + buf[j] =0; + return(1); + } else + j++; + return(0); +} so here the EOF was different and char was signed 7-bit it seems. At that time at latest i have to admit that i have not looked in old source code for years. But just had a quick look in the dmr/ of 5th revision, and there you see "char lowbyte", for example. A nice Sunday from Germany! i wish you, and the list, --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)

That makes perfect sense if you're dealing with ASCII, which is a 7-bit character set. But that assumes you were reading "characters" rather than "bytes." Binary data certainly could be any combination of 8 bits and you'd want something out of band to signal errors/eof.

On Sun, May 17, 2020 at 12:38 PM Paul Winalski <paul.winalski(a)gmail.com> wrote: Yep, I think that is the real crux of the issue. If you grew up with systems that used a 5, 6, or even a 7-bit byte; you have an appreciation of the difference. Remember, B, like BCPL, and BLISS only have a 'word' as the storage unit. But by the late 1960s, a byte had been declared (thanks to Fred Brooks shutting down Gene Amhadl's desires) at 8 bits, at least at IBM.** Of course, the issue was that ASCII was using only 7 bits to store a character. DEC was still sort of transitioning from word-oriented hardware (a lesson, Paul, you and I lived through being forgotten a few years later with Alpha); but the PDP-11, unlike the 18/36 or 12 bit systems followed IBM's lead and used the 8-bit byte and byte addressing. But that nasty 7-bit ASCII thing messed it up a little bit. When C was created (for the 8-bit byte addressed PDP-11) unlike B, Dennis introduced different types. As he says "C is quirky" and one of those quirks is that he created a "char" type, which was thus 8 bits naturally for the PDP-11, but was storing data following that 7-bit ASCII data with a bit leftover. As previously said in this discussion, to me issue is that it was called a *char,* not a *byte*. But I wonder if Dennis and team had had that foresight, it would have in practice made that much difference? It took many years and many lines of code and trying to encode the glyphs for many different natural languages to get to ideas like UTF. As someone else pointed out, one of the other quirks of C was trying to encode the return value of a function into single 'word.' But like many things in the world, we have to build it first and let it succeed before we can find real flaws. C was incredibly successful and as I said before, I'll not trade it for any other language yet it what it had allowed me and my peers to do over the years. I humbled by what Dennis did, I doubt many of us would have done as well. That doesn't make C perfect, or than we can not strive to do better, and maybe time will show Rust or Go to be that. But I suspect that may still be a long time in the future. All my CMU professors in the 1970s said Fortran was dead then. However .. remember that it still pays my salary and my company makes a ton of money building hardware that runs Fortran codes - it's not even close when you look at number one [check out: the application usage on one of the bigger HPC sites in Europe -- I offer it because it's easy to find the data and the graphics make it obvious what is happening: https://www.archer.ac.uk/status/codes/ - other sites have similar stats, but find them is harder]. Clem ** As my friend Russ Robeolen (who was the chief designer of the S/360 Model 50) tells the story, he says Amdahl was madder than a hornet about it, but Brooks pulled rank and kicked him out of his office. The S/360 was supposed to be an ASCII machine - Amdahl thought the extra bit for a byte was a waste -- Brooks told him if it wasn't a power of 2, don't come back -- that is "if a byte was not a power of two he did not know how to program for it efficiently and SW being efficient was more important that Amdahl's HW implementation!" (imagine that). Amdahl did get a 24-bit word type, but Brooks made him define it so that 32 bits stored everything, which again Amdahl thought was a waste of HW. Bell would later note that it was the single greatest design choice in the computer industry] .

On Mon, 18 May 2020, Peter Jeremy wrote: You haven't lived until you've dealt with a 1's-complement machine i.e. -0 != 0 ... To be fair, it was *mostly* normalised. Ever tried a Univac or a Honeywell? I don't remember the exact details, and I prefer to keep it that way... I had to support an old Alpha once; that was one of the reasons why I was happy to leave the joint. We had just one customer who used an Alpha, and thus we/I had to maintain the thing. And don't even ask me about HP-UX (just as well that they weren't called Packard-Hewlett), nor Xenix, nor early Slowaris, nor National Cash Registers, nor... Excuse me, I now have to take my sleepy pills :-) -- Dave

On Mon, May 18, 2020 at 8:05 AM Tony Finch <dot(a)dotat.at> wrote: Yes, that was the style of the systems language. IIRC PL/360 worked the same way too. Correct. I never used NB, so you'll have to ask someone like Ken or Doug, as to when the language became 'different enough' that Dennis felt it was time to rename it. From conversations years ago with dmr, I was under the impression the original additions were considered 'syntactic sugar ' at first -- hints to help him generate better code for the PDP-11 (like 'register'). I think Steve was at Waterloo and still using B and when he returned to MH, C had appeared, but he might be able to shed some light on the transition. Clearly the byte address behavior of the 11 had a heavy influence in C. As I said in my earlier email, I've some times wonder what would have happened to the language if the data units had been: byte, word, ptr only [or if DEC marketing had not screwed up with how BLISS was released - another story for COFF I suspect]. Clem

CDC NOS on the 6600 (I used a 70/74, actually) used 12 bits to store ASCII. Mostly, we used six bit display code. Since there was a printable character for every code, you could just look at the binary files. Ten characters to the word! Brantley

No typo. While BCD was a way of encoding digits, BCD was also used as a character encoding. Often these were outgrowths of the digit+zone punch encoding of IBM cards. IBM later extended their BCD making into…. The EXTENDED Binary Coded Decimal Interchange Code, going from 6 to 8 bits in the process.l UNIVAC indeed have their own BCD-sih format called FIELDDATA. It was notable in that the nul value printed as @. the PDP-10 and the UNVAC 1100 series were just the longest surviving perhaps of the 36 bit computers, that also included the IBM 70XX series and the GE 600 (Honewell 6000) series. Both the UNIVAC and the PDP-10 did have the nice variable partial word mode, but all of these were indeed word addressed machines. The early Crays also were word addressed. The C compiler would simulated byte addressing by putting the byte offsetinto the word in the high order bits (the address resgisters themselves were pinned at 24 bits). Just to get this back on a UNIX history track, let me delve into more trivia. Perhaps the real oddity was the Denelcor HEP. The HEP had two addressing modes: One was byte addressed (as you expect), the other was for all other data thpes (16-bit, 32-bit, and 64-bit portions of the 64-bit word). The lower 3 bits of the memory address encoded the word side. If it was 0 or 4, then it a 64 bit operand at the address specified in the higher part of the pointer. If it was 2 or 6, then it was either the upper or lower half word. If it was 1,3,5, or 7, it was one of the respective quarter words. This caused a problem when we ported 4BSD to the thing. The Berkeley kernel (particularly in the I/O code) did what I called “conversion by union.” They would store a value in a union using one type pointer and the retrieve it via a different type. In our compiler, had they used a cast (or went via a void* intermediary), everything would be fine. But doing this sort of shenanigan (which is technically undefined behavior in C) led to insidious bugs where you’d be doing pointer operations and the WRONG size word would be referenced. I spent a few days hunting all these down and fixing them. It was about this time I realized that the code was setting up I/Os using a feature aptly named “The Low Speed Bus” and that we’d never get any reasonable performance that way. HEP designer Burton Smith and I redesigned the I/O system literally on napkins from the Golden Corral in Aberdeen. We went back and built a new I/O system out of spare parts we had on hand using an 11/34 as a control processor. The HEP I/O system was kind of interesting in that while it had a highspeed interface into he HEP’s ECL memory, the thing consisted of 32 individual DEC UNIBUSes.

It technically probably always should have. Void* (which has the same format as char*) would have accepted either type pointer, char* shouldn't, though I suspect that early compilers that predate void* would have happily converted any pointer to char* (or int for that matter). -----Original Message----- From: TUHS <tuhs-bounces(a)minnie.tuhs.org> On Behalf Of Derek Fawcus Sent: Sunday, May 17, 2020 12:11 PM To: tuhs(a)tuhs.org Subject: Re: [TUHS] v7 K&R C On Fri, May 15, 2020 at 10:31:38PM +0100, Richard Tobin wrote: I was about to suggest I'd yet to come across a compiler which handled them that way, but on checking I find that both clang and gcc do now in effect have 3 types. i.e. both 'unsigned char *' and 'signed char *' values passed to a function taking 'char *' raises a warning. I wonder when they started doing that? DF