When I read Doug’s message. I figured it was sarcasm related to the voluminous warnings that are generated these days and was harkening back to some paper Lorinda Cherry wrote about how they were needless additions to the perfection that was the original C compiler (that’s sarcasm) that I had never seen before. When you responded as you did, i began to realize the error of my conception :). If I’m. understanding now, Doug wants to resurrect the Writer’s workbench amalgamation of tools, most of which were written by Lorinda Cherry and he’s wanting to eliminate all of gcc’s warnings. I suppose Lorinda Cherry might actually have approved of -Wall in principle, as there is a strong parallelism between grammars here. When I teach student to use -Wall (with clang), I tell them that it’s very handy to see all of the warnings, but to only address those that they feel are value add, so to speak. I give the same advice to the writers I advise... just cuz Word tells you not to use passive voice, doesn’t mean that it isn’t often appropriate. One specific gcc/clang warning that I get a lot goes like this: while(entry = getutxent()){ // Do stuff with entry; } Sure, it’s a tricky bit, but the printed fix is to add a set of do nothing parens: while((entry = getutxent())) Hardly edifying :). Much better would ve the explicit compare: while((entry = getutxent()) != NULL) But even that implies the programmer isn’t capable of differentiating = and ==. That said, most -Wall stuff is ok, and I’d love to see an up to date wwb kit with few to no warnings! Good luck, Will Sent from my iPhone

It has nothing to do with machine architecture. The C standard says 0 coerces to the null pointer. NULL, defined in <stddef.h>, is part of the library, not the language. I always use 0, because NULL is a frill. Doug

On Sun, Sep 20, 2020 at 4:58 PM Doug McIlroy &lt;doug(a)cs.dartmouth.edu&gt; wrote: Hmmm ... Doug - As the risk of playing language lawyer here, I'm going to argue that between sections 6.3.2.3 and 7.19 the first is legal. Cut/pasted from my cope of the 2017 standard (I don't think this has changed in later drafts): ISO/IEC 9899:2017 Section 6.3.2.3 *Pointers* *....* 1. An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.67) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. 2. 67)The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant; see 7.19. 3. .... ISO/IEC 9899:2017 Section 7.19 *Common definitions <stddef,h>* .... 1. The macros are NULL which expands to an implementation-defined null pointer constant; For whatever its worth, in a number of common coding standards where I have worked, have always required that when NULL was used, it was always cast first to the actual data type. Yes, this is verbose, but it means that a casual reader sees the type and in particularly in a commerical SW development setting, that is money in the bank from a maintence standpoint -- IIRC Gimpel's flexelint <https://www.gimpel.com/about.html> (which IMO oppinion was always the best lint around), has a switch that will force that behavior. As I understand it, the idea behind -Wall *et al*, is that if we can get code to be 'flexelint clean' the number of latent bugs drops dramatically. This is particularly true when dealing with code that started be written on a system with one word or pointer size and now needs to run elsewhere; which is a common issue commerical ISVs live a great deal [this is a codified in the 10th of Henry's commandments: Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that ``All the world's a VAX'', and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current machine be short. : .

On Sun, 20 Sep 2020, Doug McIlroy wrote: I was under the impression that there was explicitly no requirement that a null pointer be 0, and that there was at least one weird system where that wasn't true - that it just so happened that null points to 0 on certain CPUs and that 0=NULL *happens* to work on most CPUs but wasn't guaranteed. (In fact, I read that my habit of using 0 for NULL relied on a faulty assumption!) I mean, I've never actually used a CPU/OS/compiler where it wasn't true, but... -uso.

This discussion of null pointers reminds me of one of the hardest things we came upon porting what became V7 to the Interdata 4/32. Earlier UNIX systems had returned -1 as an error indicator from some system calls that returned a pointer. We made a strong effort to find these, but they were everywhere and we didn't get them all (another motivation for Lint...). We were finding crashes on the Interdata with the machine halted and none of the error registers (including the location of the fault) making any sense. After a couple of frustrating weeks, we found the problem. The Interdata was a microcoded machine. If it tried to access -1 as an address, it immediately got an "unaligned access" fault and dove into the microcode. Before it has saved its status registers, the memory system chimed in with another fault -- memory access out of bounds. The combination trashed everything. When we met with Interdata to explore whether they wanted to sell Unix on their hardware, fixing this was one of our non-negotiable demands. They said no. We walked. Several years later, of course, Unix did show up there, but they missed a great opportunity. --- On 2020-09-20 14:33, Brantley Coile wrote:

At Sun, 20 Sep 2020 17:35:52 -0400, John Cowan &lt;cowan(a)ccil.org&gt; wrote: Subject: Re: [TUHS] reviving a bit of WWB Yeah, that's more to do with the good/bad choice in C to do or not do integer promotion in various situations, and to default parameter types to 'int' unless they are, or are cast to, a wider type (and of course with the rather tricky and almost non-portable way C allows variable length argument lists, along with the somewhat poor way C was cajoled into offering function prototypes to support separate compilation of code units and the exceedingly poor way prototypes deal with variable length argument lists). -- 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;

On Tue, 2 Feb 2021, Larry McVoy wrote: Holy smoking inodes! I'd forgotten that story... And yes, I really was approached by Pr1me, and really did turn them down on the basis that if they thought that "1" was prime then what else did they get wrong?[*] Oh, they went belly-up shortly afterwards, so it was probably just as well (plainly the innumerate marketoids were in charge). [*] If you assume that "1" is prime then it breaks all sorts of higher (and obscure) maths. -- Dave

BBN made a machine "optimized" for C. It was used in the first generation ARPAnet gateways. A word was 10bits. The amount of masking we had to do for some portable software was unreal.

How about 23-bits? That was one of the early ESS machines, evidently optimized to make every bit count. (Maybe a prime wordwidth helps with hashing?) Whirlwind II (built in 1952), was 16 bits. It took a long while for that to become common wisdom. Doug On Tue, Feb 2, 2021 at 10:32 PM Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote:

On Wed, 3 Feb 2021, Peter Jeremy wrote: Best reason I can think of is System/360 with 8-bit EBCDIC (Ugh! Who said that "J" should follow "I"?). I'm told that you could coerce it into using ASCII, although I've never seen it. Why would you want to have a 7-bit symbol? Powers of two seem to be natural on a binary machine (although there is a running joke that CDC boxes has 7-1/2 bit bytes... I guess the real question is why did we move to binary machines at all; were there ever any ternary machines? -- Dave

System/360s, or at least 370s, could do ASCII perfectly well. When we started UNIX on VM/370, it was clear to us that we wanted to run with ASCII. But some otherwise intelligent people told us that it *just couldn't be done* - the instructions depended on EBCDIC. But I think there was only 1 machine instruction with any hint of EBCDIC - and it was an instruction that no-one could imagine being used by a compiler, Of course, plenty of EBCDIC/ASCII conversions went on in drivers, etc, but that was easy. On Wed, Feb 3, 2021 at 12:09 PM Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote: -- - Tom

Yup. Before my time. I didn't get to use it until 1954. Doug On Wed, Feb 3, 2021 at 5:19 PM Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote: > On Tue, 2 Feb 2021, M Douglas McIlroy wrote: > > > > I'm trying to get my head around a 10-bit machine optimised for C. > > > > How about 23-bits? That was one of the early ESS machines, evidently > > optimized to make every bit count. (Maybe a prime wordwidth helps with > > hashing?) > > 23 bits? I think I'm about to throw up... Yeah, being prime I suppose it > would help with hashing (and other crypto stuff). > > > Whirlwind II (built in 1952), was 16 bits. It took a long while for that > > to become common wisdom. > > > -- Dave >

The confusion (I dare not call it a flame war) is arising out of the difference between an object with all bits zero and a 0 constant (or equivalently 2*0 or 3-3 or what not). 0 in pointer context is always a null pointer, but it may or may not be all-bits-zero. 0 in integer context is, on any sane machine, all-bits-zero (on 1's-complement machines it may also be all-bits-one). Personally, when I was programming in C I defined a macro #define NULLPTR(t) ((t)0), so that I would write NULLPTR(char *) or NULLPTR(int *) or whatever the Right Thing was. On Sun, Sep 20, 2020 at 6:16 PM Clem Cole &lt;clemc(a)ccc.com&gt; wrote:

Steve Nickolas wrote in &lt;alpine.DEB.2.21.2009201654300.10605(a)sd-119843.dedibox.fr&gt;fr>: |On Sun, 20 Sep 2020, Doug McIlroy wrote: | |>> (Of course, that assumes NULL is 0, but I don't think I've run into any |>> architecture so braindead as to not have NULL=0.) |> |> It has nothing to do with machine architecture. The C standard |> says 0 coerces to the null pointer. NULL, defined in <stddef.h>, |> is part of the library, not the language. I always use 0, |> because NULL is a frill. |> |> Doug | |I was under the impression that there was explicitly no requirement that a |null pointer be 0, and that there was at least one weird system where that |wasn't true - that it just so happened that null points to 0 on certain |CPUs and that 0=NULL *happens* to work on most CPUs but wasn't guaranteed. |(In fact, I read that my habit of using 0 for NULL relied on a faulty |assumption!) | |I mean, I've never actually used a CPU/OS/compiler where it wasn't true, |but... I remember having to use __null for __GNUC__>=3 because 0x0 (what is used for my NIL macro before, this was C++) did not work out well. (Could have been compiler bug, of course .. but i just remembered it when reading your post.) --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)

Dave: Seymour used ones complement on the 3000 and 6000 series. Maybe there? The primary HLLs I used on the CDC boxes were FTN and Pascal, but I would not be surprised if that was were you saw it. On Wed, Sep 23, 2020 at 10:26 PM Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote:

On Thu, Sep 24, 2020 at 6:20 PM Greg 'groggy' Lehey &lt;grog(a)lemis.com&gt; wrote: Don't know about the others, but I'm pretty sure PDP-10 wasn't 1's compliment / was 2's compliment.. Warner

On Wed, 23 Sep 2020, Clem Cole wrote: Could be CDC, yeah, but this was a few decades ago... -- Dave

On Thu, Sep 24, 2020 at 1:19 PM Paul Winalski &lt;paul.winalski(a)gmail.com&gt; wrote: Or separate-sign numerical representations, for that matter, such as IEEE floats are still sign-magnitude, for that matter, both the binary ones and the little-used decimal ones, which is why MAX_FLOAT and MAX_DOUBLE are the same in both positive and negative directions. I once had to deal with some mainframe data that had been transferred to our PDP-11 or Vax (not sure which), and I noticed right away that some of the allegedly numeric data had a non-digit immediately following and one fewer significant digit than the rest. A little digging in my memory (I think this was before I got access to the Internet in 1985 or so), plus a little experimentation, established that these were trailing-overpunched-sign numbers that had been mechanically translated from EBCDIC to ASCII. So on the principle of "If a problem is not interesting, generalize it until it is", I wrote a little filter that looked for such numbers in its input and rewrote them as leading-separate-sign (i.e. the Usual Way), copying everything else. Unfortunately the source is long since lost, but I wouldn't write it in C today anyway.

Hello Steve, scj(a)yaccman.com wrote: On my Ubuntu Linux system: $ ls -l /usr/share/dict total 2372 -rw-r--r-- 1 root root 971578 Oct 20 2017 american-english -rw-r--r-- 1 root root 967402 Oct 20 2017 british-english -rw-r--r-- 1 root root 477238 Aug 4 2017 cracklib-small -rw-r--r-- 1 root root 199 Oct 10 2016 README.select-wordlist lrwxrwxrwx 1 root root 30 Mar 31 2020 words -> /etc/dictionaries-common/words lrwxrwxrwx 1 root root 16 Mar 31 2020 words.pre-dictionaries-common -> american-english $ ls -l /etc/dictionaries-common/words lrwxrwxrwx 1 root root 32 Mar 31 2020 /etc/dictionaries-common/words -> /usr/share/dict/american-english And my port of Doug's spell(1) from V10 (see my github): $ ls src/v10spell/ american brspell.v10 list mkfile README.md spellsh.in stop amspell.v10 ChangeLog local pcode.c spell.1 spell-wrapper.sh tools british code.h makefile README spell.pdf sprog.c HTH, Arnold

SCOWL <http://wordlist.aspell.net> is, unlike almost all open-source wordlists, a *very* thoroughly screened source of spelling words. It has many sub-lists that allow you to construct en-US, en-GB, en-GB-oed (British spelling with -ize), en-CA, and en-AU spelling lists of various sizes, or any combinations of them. You can create them in traditional one-word-per-line format, Aspell format, or Hunspell format. List sizes vary from size 10 at 4500 words (e.g. avoid, dedicated, everything, goes, killed, quicker, should, simultaneously, virtue, weird) to size 95 at 230,000 (e.g. adlumidine, alinasal, hartake, miscegenationists, sigillaria, staphyledema, unruth). Larger list sizes have rarer words, some of which are more likely to be misspellings: "suer", one who sues, is usually a typo for "user", so it only appears in size 70 and up. In addition, you can mix in special lists: hacker words (like "grepped"), taboo words, Roman numerals, etc. There's a web page and a Perl script to do the mixing, but you can do it by hand too. John Cowan http://vrici.lojban.org/~cowan cowan(a)ccil.org When I'm stuck in something boring where reading would be impossible or rude, I often set up math problems for myself and solve them as a way to pass the time. --John Jenkins