The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] reviving a bit of WWB
@ 2020-09-20 22:51 Norman Wilson
  0 siblings, 0 replies; 44+ messages in thread
From: Norman Wilson @ 2020-09-20 22:51 UTC (permalink / raw)
  To: tuhs

Brantley Coile:

  The fact that a pointer of zero generates a hardware trap is not
  defined in the language, whereas a 0 is is defined to be a null pointer.

=====

The language doesn't require that dereferencing a null pointer
cause a trap, either.  There's no way to guarantee that behaviour
in all environments unless every pointer dereference must include
instructions to check for the null-pointer value, because C can
run in environments in which any pointer value might be a valid
address.

On modern machines it's conventional for the null-pointer value
in C, what you get when you assign 0 to a pointer, to be all-zeroes;
and for operating systems to arrange that that address is unmapped.
But that wasn't always so (on the PDP-7 there was no memory map;
on the PDP-11 once memory-mapping was added, address space was
too dear to throw away an eighth of it just to block null-pointer
dereferencing), and it may still not be (consider a C program
on an embedded system running without a memory map).

It's good that modern systems usually whap you in the head if you
deference a null pointer, but it's not required, and those who
rely on it are as foolish as those who used to rely on the
accident that the byte at address 0 on early VAX UNIX was a zero.

Norman Wilson
p&p6 and f(

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-10-08  0:27     ` Dave Horsfall
@ 2020-10-08  3:08       ` John Cowan
  0 siblings, 0 replies; 44+ messages in thread
From: John Cowan @ 2020-10-08  3:08 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

 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@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

[-- Attachment #2: Type: text/html, Size: 1671 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-10-07  5:47   ` scj
  2020-10-07  9:20     ` arnold
@ 2020-10-08  0:27     ` Dave Horsfall
  2020-10-08  3:08       ` John Cowan
  1 sibling, 1 reply; 44+ messages in thread
From: Dave Horsfall @ 2020-10-08  0:27 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Tue, 6 Oct 2020, scj@yaccman.com wrote:

> About once a month I wish I had /usr/dict/words on my machine...

You don't?

Daves-MacBook-Pro:~ dave$ wc -l lib/*words
   644785 lib/allwords
    45402 lib/linuxwords
   235886 lib/words (a symlink to the system dictionary)
   926073 total

("allwords" is just a combined FreeBSD/Linux words, with dups removed).

Very useful for solving word puzzles in newspapers...

-- Dave

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-10-07  5:47   ` scj
@ 2020-10-07  9:20     ` arnold
  2020-10-08  0:27     ` Dave Horsfall
  1 sibling, 0 replies; 44+ messages in thread
From: arnold @ 2020-10-07  9:20 UTC (permalink / raw)
  To: scj, arnold; +Cc: tuhs, doug

Hello Steve,

scj@yaccman.com wrote:

> About once a month I wish I had /usr/dict/words on my machine...

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

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 18:42 ` arnold
  2020-09-20 19:28   ` Will Senn
@ 2020-10-07  5:47   ` scj
  2020-10-07  9:20     ` arnold
  2020-10-08  0:27     ` Dave Horsfall
  1 sibling, 2 replies; 44+ messages in thread
From: scj @ 2020-10-07  5:47 UTC (permalink / raw)
  To: arnold; +Cc: tuhs, doug

About once a month I wish I had /usr/dict/words on my machine...

---


On 2020-09-20 11:42, arnold@skeeve.com wrote:
> Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> 
>> I would like to revive Lorinda Cherry's "parts".
>> Implicit in "revival" is dispelling the hundreds
>> of warnings from  gcc -Wpedantic -Wall -Wextra.
>> Has anybody done this already?
>> 
>> Doug
> 
> I haven't tried this. I do suggest starting with 'gcc -m32' so that
> you're not fighting 64 bit issues at the same time as everything else.
> 
> HTH,
> 
> Arnold

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 21:33           ` Brantley Coile
@ 2020-10-07  5:43             ` scj
  0 siblings, 0 replies; 44+ messages in thread
From: scj @ 2020-10-07  5:43 UTC (permalink / raw)
  To: Brantley Coile; +Cc: tuhs, Doug McIlroy

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:
> The fact that a pointer of zero generates a hardware trap is not
> defined in the language, whereas a 0 is is defined to be a null
> pointer.
> 
> I've worked on systems where a 0 pointer could be dereferenced without
> a trap. I wouldn't recommend it. System designers do things like make
> the first page of memory invalid so we will get a null pointer trap.
> On Plan 9 the beginning of the text segment starts at 0x1020.
> 
> But that's not part of the C language. The fact that 0 is a null 
> pointer is.
> 
> Brantley
> 
>> On Sep 20, 2020, at 4:58 PM, Steve Nickolas <usotsuki@buric.co> wrote:
>> 
>> 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...
>> 
>> -uso.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-25 14:19 Doug McIlroy
@ 2020-09-28 17:35 ` Angelo Papenhoff
  0 siblings, 0 replies; 44+ messages in thread
From: Angelo Papenhoff @ 2020-09-28 17:35 UTC (permalink / raw)
  To: tuhs

On 25/09/20, Doug McIlroy wrote:
> > Turing save us from 1-complement machines!
> 
> Users of Whirlwind II were warned about the quirks of -0.
> We were not warned, though, about integer divide with remainder 0.
> The result of dividing 6 by 3, for example, was binary 1.111111... -
> a valid answer when carried to infinity. Unfortunately, the
> "fractional" part was dropped.
> 
> Most people used Whirlwind for floating-point computation, and
> blithely dismissed printed answers like 1.999999 as "roundoff
> errors".

It's funny that you mention that. I'm working on a verilog simulation of
the Whirlwind I right now and I *just* came across this quirk. Now I'm
really glad I remembered this mail of yours. Otherwise I might have
spent some time trying to debug this non-bug. Thanks a lot!

(The simulation is based on the description from 1947, so it doesn't
describe the machine as it actually ran in the 50s. It would be great to
have more material on its later life.)

aap

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-24  2:33         ` Clem Cole
@ 2020-09-27  5:54           ` Dave Horsfall
  0 siblings, 0 replies; 44+ messages in thread
From: Dave Horsfall @ 2020-09-27  5:54 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

On Wed, 23 Sep 2020, Clem Cole wrote:

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

Could be CDC, yeah, but this was a few decades ago...

-- Dave

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
@ 2020-09-25 14:19 Doug McIlroy
  2020-09-28 17:35 ` Angelo Papenhoff
  0 siblings, 1 reply; 44+ messages in thread
From: Doug McIlroy @ 2020-09-25 14:19 UTC (permalink / raw)
  To: tuhs

> Turing save us from 1-complement machines!

Users of Whirlwind II were warned about the quirks of -0.
We were not warned, though, about integer divide with remainder 0.
The result of dividing 6 by 3, for example, was binary 1.111111... -
a valid answer when carried to infinity. Unfortunately, the
"fractional" part was dropped.

Most people used Whirlwind for floating-point computation, and
blithely dismissed printed answers like 1.999999 as "roundoff
errors".

Doug

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-24 17:19         ` Paul Winalski
@ 2020-09-24 18:17           ` John Cowan
  0 siblings, 0 replies; 44+ messages in thread
From: John Cowan @ 2020-09-24 18:17 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

On Thu, Sep 24, 2020 at 1:19 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

Or separate-sign numerical representations, for that matter, such as
> the IBM 1620 had.  And packed decimal on the S/360/370 and the VAX.
> Negative zero in packed decimal is responsible for a lot of the
> "computerized bill for $0.00" bugs that were rife in the 1960s.
>

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.

[-- Attachment #2: Type: text/html, Size: 1874 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-24  2:25       ` Dave Horsfall
  2020-09-24  2:33         ` Clem Cole
@ 2020-09-24 17:19         ` Paul Winalski
  2020-09-24 18:17           ` John Cowan
  1 sibling, 1 reply; 44+ messages in thread
From: Paul Winalski @ 2020-09-24 17:19 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On 9/23/20, Dave Horsfall <dave@horsfall.org> wrote:
>
> Turing save us from 1-complement machines!
>
Or separate-sign numerical representations, for that matter, such as
the IBM 1620 had.  And packed decimal on the S/360/370 and the VAX.
Negative zero in packed decimal is responsible for a lot of the
"computerized bill for $0.00" bugs that were rife in the 1960s.

-Paul W.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-24  2:25       ` Dave Horsfall
@ 2020-09-24  2:33         ` Clem Cole
  2020-09-27  5:54           ` Dave Horsfall
  2020-09-24 17:19         ` Paul Winalski
  1 sibling, 1 reply; 44+ messages in thread
From: Clem Cole @ 2020-09-24  2:33 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

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 <dave@horsfall.org> wrote:

> On Sun, 20 Sep 2020, Steve Nickolas 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.)
>
> I don't remember the details mow, but I recall an architecture where NULL
> was -0...  Turing save us from 1-complement machines!
>
> -- Dave
>

[-- Attachment #2: Type: text/html, Size: 1172 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 20:12     ` Steve Nickolas
  2020-09-20 20:26       ` Doug McIlroy
@ 2020-09-24  2:25       ` Dave Horsfall
  2020-09-24  2:33         ` Clem Cole
  2020-09-24 17:19         ` Paul Winalski
  1 sibling, 2 replies; 44+ messages in thread
From: Dave Horsfall @ 2020-09-24  2:25 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Sun, 20 Sep 2020, Steve Nickolas 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.)

I don't remember the details mow, but I recall an architecture where NULL 
was -0...  Turing save us from 1-complement machines!

-- Dave

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21 23:56             ` John Cowan
@ 2020-09-22  0:54               ` Richard Salz
  0 siblings, 0 replies; 44+ messages in thread
From: Richard Salz @ 2020-09-22  0:54 UTC (permalink / raw)
  To: John Cowan; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 113 bytes --]

Getting back to the original topic, would this port/refresh of WWB include
style&diction and be redistributable?

[-- Attachment #2: Type: text/html, Size: 164 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21 21:57           ` Clem Cole
@ 2020-09-21 23:56             ` John Cowan
  2020-09-22  0:54               ` Richard Salz
  0 siblings, 1 reply; 44+ messages in thread
From: John Cowan @ 2020-09-21 23:56 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

On Mon, Sep 21, 2020 at 5:57 PM Clem Cole <clemc@ccc.com> wrote:


> As the more and more features got added, the focus of the language changed
> ... ney Chisnall's 2018 screed: C is not a low level language
> <https://queue.acm.org/detail.cfm?id=3212479>
>

Rereading that made me wonder: if someone retargeted an old compiler (pcc,
say) to produce i386 code, how much faster would it run than a VAX?  I see
that there is a pcc derivative at <http://pcc.ludd.ltu.se/>, but supposedly
it has been heavily rewritten for C99 compliance and other things.

Not nearly as bad as the pile we got with 'modern' C++ [which I'm loath to
> use].
>

You should be.  It's loathsome.  :-)

[-- Attachment #2: Type: text/html, Size: 1443 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21 21:22         ` Rob Pike
@ 2020-09-21 21:57           ` Clem Cole
  2020-09-21 23:56             ` John Cowan
  0 siblings, 1 reply; 44+ messages in thread
From: Clem Cole @ 2020-09-21 21:57 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]

Right .. I remember running into/using that idiom in a couple of places in
a few other drivers in the early years.  I also remember working one of the
CAD tools (it may have been one of the UCB CAD editors) which were very
graphics centric and running into it there.

I always looked at this as part of the original C heritage from simpler
times *i.e.* from ESPOL/BCPL/B and the like, when it was still considered a
'low level' language that mapped well to the HW at hand.  As the more and
more features got added, the focus of the language changed ... ney
Chisnall's 2018 screed: C is not a low level language
<https://queue.acm.org/detail.cfm?id=3212479>   Not nearly as bad as the
pile we got with 'modern' C++ [which I'm loath to use].

Clem

On Mon, Sep 21, 2020 at 5:23 PM Rob Pike <robpike@gmail.com> wrote:

> Back when we were running v5 at the University of Toronto, we had a
> graphics device that we accessed, on our split I&D space 11/45, using 0,
> something like this:
>
> struct x {
>    int reg0, reg1, ...;
> };
>
> 0->reg1 = 0234;
>
> Several old details of old C made this possible as well: Struct tags were
> global, -> worked on any pointer, and ints and pointers were
> interchangeable.
>
> -rob
>
>
> On Tue, Sep 22, 2020 at 6:51 AM John Cowan <cowan@ccil.org> wrote:
>
>>
>>
>> On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas <usotsuki@buric.co> wrote:
>>
>>
>>> I've never written anything that uses varargs, so I've never run into
>>> that.  But I've actually done quite a bit of work with an environment
>>> where this isn't true: MS-DOS using the large or huge model.  In this
>>> environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not
>>> conformant to pass an int variable as an argument where a pointer variable
>>> is expected.
>>>
>>
>> If the compiler was ISO-conformant (which it almost certainly was not),
>> that would not matter.  0 in int context would be a 2-byte int with all
>> bits zero, and 0 in pointer context would be a 4-byte null pointer,
>> probably with all bits zero.
>>
>> C doesn't require that the address represented by the null pointer
>> (whether or not it is all-bits-zero) is inaccessible, merely that there is
>> no C object or function there.  A simple shim of the appropriate size (1,
>> 2, 4, 8 bytes depending on the CPU's alignment rules) will suffice.
>>
>>

[-- Attachment #2: Type: text/html, Size: 3848 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21 20:50       ` John Cowan
  2020-09-21 21:22         ` Rob Pike
@ 2020-09-21 21:39         ` Steve Nickolas
  1 sibling, 0 replies; 44+ messages in thread
From: Steve Nickolas @ 2020-09-21 21:39 UTC (permalink / raw)
  To: John Cowan; +Cc: The Eunuchs Hysterical Society

On Mon, 21 Sep 2020, John Cowan wrote:

> On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas <usotsuki@buric.co> wrote:
>
>
>> I've never written anything that uses varargs, so I've never run into
>> that.  But I've actually done quite a bit of work with an environment
>> where this isn't true: MS-DOS using the large or huge model.  In this
>> environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not
>> conformant to pass an int variable as an argument where a pointer variable
>> is expected.
>>
>
> If the compiler was ISO-conformant (which it almost certainly was not),
> that would not matter.  0 in int context would be a 2-byte int with all
> bits zero, and 0 in pointer context would be a 4-byte null pointer,
> probably with all bits zero.

The compiler I used at least tried to be C89. (Borland Turbo C++ 1.01)

> C doesn't require that the address represented by the null pointer (whether
> or not it is all-bits-zero) is inaccessible, merely that there is no C
> object or function there.  A simple shim of the appropriate size (1, 2, 4,
> 8 bytes depending on the CPU's alignment rules) will suffice.

Which was nice with the tiny model: a .COM file organized at near 0x0100, 
and iirc, there was guaranteed to be 0xCD 0x20 at 0x0000.  (The 8086 "INT 
20H" instruction.  I just checked in DOSEMU with PC DOS 7, and that is 
exactly what shows up there.)

"ANSI C" doesn't mean a lot though when 95% of the code I run across uses 
extensions.  I still have not successfully kitbashed the Bourne shell onto 
native DOS, OS/2 or Windows without an emulation layer - in any form.  Did 
come *pretty* close with the Forsyth shell but I couldn't work around the 
lack of fork() (OS/2 does have a near-exact counterpart for pipe(), but 
it's not exposed by the pipe() call for some reason.)  I like my Unix 
shells even on Microsoft OSes...call me crazy. ;)

-uso.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21 20:50       ` John Cowan
@ 2020-09-21 21:22         ` Rob Pike
  2020-09-21 21:57           ` Clem Cole
  2020-09-21 21:39         ` Steve Nickolas
  1 sibling, 1 reply; 44+ messages in thread
From: Rob Pike @ 2020-09-21 21:22 UTC (permalink / raw)
  To: John Cowan; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

Back when we were running v5 at the University of Toronto, we had a
graphics device that we accessed, on our split I&D space 11/45, using 0,
something like this:

struct x {
   int reg0, reg1, ...;
};

0->reg1 = 0234;

Several old details of old C made this possible as well: Struct tags were
global, -> worked on any pointer, and ints and pointers were
interchangeable.

-rob


On Tue, Sep 22, 2020 at 6:51 AM John Cowan <cowan@ccil.org> wrote:

>
>
> On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas <usotsuki@buric.co> wrote:
>
>
>> I've never written anything that uses varargs, so I've never run into
>> that.  But I've actually done quite a bit of work with an environment
>> where this isn't true: MS-DOS using the large or huge model.  In this
>> environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not
>> conformant to pass an int variable as an argument where a pointer variable
>> is expected.
>>
>
> If the compiler was ISO-conformant (which it almost certainly was not),
> that would not matter.  0 in int context would be a 2-byte int with all
> bits zero, and 0 in pointer context would be a 4-byte null pointer,
> probably with all bits zero.
>
> C doesn't require that the address represented by the null pointer
> (whether or not it is all-bits-zero) is inaccessible, merely that there is
> no C object or function there.  A simple shim of the appropriate size (1,
> 2, 4, 8 bytes depending on the CPU's alignment rules) will suffice.
>
>

[-- Attachment #2: Type: text/html, Size: 2284 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21  5:55     ` Steve Nickolas
  2020-09-21  5:59       ` Warner Losh
@ 2020-09-21 20:50       ` John Cowan
  2020-09-21 21:22         ` Rob Pike
  2020-09-21 21:39         ` Steve Nickolas
  1 sibling, 2 replies; 44+ messages in thread
From: John Cowan @ 2020-09-21 20:50 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas <usotsuki@buric.co> wrote:


> I've never written anything that uses varargs, so I've never run into
> that.  But I've actually done quite a bit of work with an environment
> where this isn't true: MS-DOS using the large or huge model.  In this
> environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not
> conformant to pass an int variable as an argument where a pointer variable
> is expected.
>

If the compiler was ISO-conformant (which it almost certainly was not),
that would not matter.  0 in int context would be a 2-byte int with all
bits zero, and 0 in pointer context would be a 4-byte null pointer,
probably with all bits zero.

C doesn't require that the address represented by the null pointer (whether
or not it is all-bits-zero) is inaccessible, merely that there is no C
object or function there.  A simple shim of the appropriate size (1, 2, 4,
8 bytes depending on the CPU's alignment rules) will suffice.

[-- Attachment #2: Type: text/html, Size: 1405 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 22:47             ` John Cowan
@ 2020-09-21 20:48               ` Steffen Nurpmeso
  0 siblings, 0 replies; 44+ messages in thread
From: Steffen Nurpmeso @ 2020-09-21 20:48 UTC (permalink / raw)
  To: John Cowan; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

John Cowan wrote in
 <CAD2gp_SV19s6yHsdApn8Rfkgb3OZCVFdd++_MWTsX5b7c_Jbig@mail.gmail.com>:
 |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.

And i think too that POSIX is about to define this explicitly in
the future (regarding all bits zero).

--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)

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 20:58         ` Steve Nickolas
                             ` (2 preceding siblings ...)
  2020-09-20 22:15           ` Clem Cole
@ 2020-09-21 20:46           ` Steffen Nurpmeso
  3 siblings, 0 replies; 44+ messages in thread
From: Steffen Nurpmeso @ 2020-09-21 20:46 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: tuhs, Doug McIlroy

Steve Nickolas wrote in
 <alpine.DEB.2.21.2009201654300.10605@sd-119843.dedibox.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)

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 22:13           ` Clem Cole
@ 2020-09-21 20:43             ` Steffen Nurpmeso
  0 siblings, 0 replies; 44+ messages in thread
From: Steffen Nurpmeso @ 2020-09-21 20:43 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

Clem Cole wrote in
 <CAC20D2Mxf6vwDDd2g7cvod8uBihH50htaAgsiXYJ7zvZ_NsJjQ@mail.gmail.com>:
 |On Sun, Sep 20, 2020 at 4:58 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote:
 |>
 |> To put it more strongly. this is not a legal C source file.
 |>         char *s = NULL;
 |> But this is.
 |>         char *s = 0;
 |>
 |
 |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.

You need to include the header file to compile it though.
I guessed this is what he referred to?

--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)

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21 18:40         ` Paul Winalski
@ 2020-09-21 19:56           ` Dan Cross
  0 siblings, 0 replies; 44+ messages in thread
From: Dan Cross @ 2020-09-21 19:56 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Mon, Sep 21, 2020 at 2:40 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

> VAX/VMS was the first operating system I encountered where 0 was not a
> valid program address.  As was mentioned previously, address space on
> early machines was too precious to throw away a whole page of it just
> to catch bad null pointer references.
>
> I once saw a C program that depended on 0 being a valid pointer
> address, and on a 0x00 byte being at memory address 0.  The program
> had a bunch of char* pointers that were used in a printf() call,
> something like:
>
> printf("%s%s%s%s\n", a, b, c, d);
>
> If you didn't want, say, the third string printed, you assigned NULL
> to variable c.  That caused c to point to location 0, and printf()
> interpreted the 0 byte as the empty string "".
>
> It was hell getting this program to work on the VAX.


That sounds annoying, but not necessarily insurmountable? I imagine you
could wrap it in something like:

void
print4(char *a, char *b, char *c, char *d)
{
        if (a == NULL) a = "";
        if (b == NULL) b = "";
        if (c == NULL) c = "";
        if (d == NULL) d = "";
        printf("%s%s%s%s\n", a, b, c, d);
}

?

I guess if it was more complex than that, like say being variadic, it'd be
really annoying because you'd have to walk the arguments and accumulate
them and assign pointers to empty strings as appropriate, or just wrap
printf and interpret the format string.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 2339 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21  5:59       ` Warner Losh
@ 2020-09-21 18:40         ` Paul Winalski
  2020-09-21 19:56           ` Dan Cross
  0 siblings, 1 reply; 44+ messages in thread
From: Paul Winalski @ 2020-09-21 18:40 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

VAX/VMS was the first operating system I encountered where 0 was not a
valid program address.  As was mentioned previously, address space on
early machines was too precious to throw away a whole page of it just
to catch bad null pointer references.

I once saw a C program that depended on 0 being a valid pointer
address, and on a 0x00 byte being at memory address 0.  The program
had a bunch of char* pointers that were used in a printf() call,
something like:

printf("%s%s%s%s\n", a, b, c, d);

If you didn't want, say, the third string printed, you assigned NULL
to variable c.  That caused c to point to location 0, and printf()
interpreted the 0 byte as the empty string "".

It was hell getting this program to work on the VAX.

-Paul W.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21  5:55     ` Steve Nickolas
@ 2020-09-21  5:59       ` Warner Losh
  2020-09-21 18:40         ` Paul Winalski
  2020-09-21 20:50       ` John Cowan
  1 sibling, 1 reply; 44+ messages in thread
From: Warner Losh @ 2020-09-21  5:59 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

On Sun, Sep 20, 2020, 11:55 PM Steve Nickolas <usotsuki@buric.co> wrote:

> On Sun, 20 Sep 2020, Warner Losh wrote:
>
> > 0 is fine if sizeof(int) == sizeof(void *). Otherwise varadic function
> > calls break.
>
> I've never written anything that uses varargs, so I've never run into
> that.  But I've actually done quite a bit of work with an environment
> where this isn't true: MS-DOS using the large or huge model.  In this
> environment, sizeof(int)=2, and sizeof(void*) is 4.
>

Sizeof(int) == 4 and sizeof(void *) == 8 on LP64 platforms too...

Warner

>

[-- Attachment #2: Type: text/html, Size: 1149 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21  0:09   ` Warner Losh
  2020-09-21  1:05     ` Clem Cole
@ 2020-09-21  5:55     ` Steve Nickolas
  2020-09-21  5:59       ` Warner Losh
  2020-09-21 20:50       ` John Cowan
  1 sibling, 2 replies; 44+ messages in thread
From: Steve Nickolas @ 2020-09-21  5:55 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

On Sun, 20 Sep 2020, Warner Losh wrote:

> 0 is fine if sizeof(int) == sizeof(void *). Otherwise varadic function
> calls break.

I've never written anything that uses varargs, so I've never run into 
that.  But I've actually done quite a bit of work with an environment 
where this isn't true: MS-DOS using the large or huge model.  In this 
environment, sizeof(int)=2, and sizeof(void*) is 4.

-uso.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21  0:00   ` Clem Cole
@ 2020-09-21  2:24     ` John Cowan
  0 siblings, 0 replies; 44+ messages in thread
From: John Cowan @ 2020-09-21  2:24 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2886 bytes --]

ISO requires that NULL be defined in locale.h, stddef.h, stdio.h, stdlib.h,
string.h, time.h, wchar.h, and their C++ equivalents clocale etc..  It's
pretty unlikely that you can write any useful code at all without NULL
being defined as a side effect.

On Sun, Sep 20, 2020 at 8:01 PM Clem Cole <clemc@ccc.com> wrote:

> I was also stating (under Henry’s 10th) using a properly defined macro
> with the complete cast scheme will be correct and portable to all known
> conforming C compilers no matter the target HW architecture — which in a
> commercial SW setting is highly valued.
>
> Clem
>
> On Sun, Sep 20, 2020 at 7:53 PM Clem Cole <clemc@ccc.com> wrote:
>
>> Norman NULL has to be defined and I said that/showed it.   The standard
>> says where.  I was not trying to compile NULL without a definition which I
>> agree it not legal.  If that is what Doug was implying I missed understood
>> him but I note NULL was introduced in Typesetter C /V7 where those compiler
>> s set it to 0 in studio but the ANSI/ISO moved it.
>>
>> On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson <norman@oclsc.org> wrote:
>>
>>> Doug McIlroy:
>>>
>>>
>>>
>>>   To put it more strongly. this is not a legal C source file.
>>>
>>>           char *s = NULL;
>>>
>>>   But this is.
>>>
>>>           char *s = 0;
>>>
>>>
>>>
>>> Clem Cole:
>>>
>>>
>>>
>>>    67)The macro NULL is defined in <stddef.h> (and other headers) as a
>>> null
>>>
>>>    pointer constant; see 7.19.
>>>
>>>
>>>
>>> ====
>>>
>>>
>>>
>>> $ cat null.c
>>>
>>> char *s = NULL;
>>>
>>> $ cat zero.c
>>>
>>> char *s = 0;
>>>
>>> $
>>>
>>>
>>>
>>> zero.c is a legal C program.  null.c is not.  Create
>>>
>>> files exactly as shown and compile them if you don't
>>>
>>> believe me.
>>>
>>>
>>>
>>> Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
>>>
>>> to null.c and it becomes legal, but I think that's Doug's
>>>
>>> point: you need an include file.
>>>
>>>
>>>
>>> Personally I prefer to use NULL instead of 0 when spelling
>>>
>>> out a null pointer, because I think it's clearer:
>>>
>>>         if ((buf = malloc(SIZE)) == NULL)
>>>
>>>                 error("dammit andrew");
>>>
>>> though I am willing to omit it when there's no confusion
>>>
>>> about = vs ==:
>>>
>>>         if (*p)
>>>
>>>                 dammit(*p, "andrew");
>>>
>>>
>>>
>>> But that's just a question of style, and Doug's is fine too.
>>>
>>>
>>>
>>> The language does not require the compiler to pre-define
>>>
>>> NULL or to recognize it as a keyword; you have to include
>>>
>>> an appropriate standard header file.
>>>
>>>
>>>
>>> Norman Wilson
>>>
>>> Toronto ON (not 0N nor NULLN)
>>>
>>> --
>> Sent from a handheld expect more typos than usual
>>
>>
>> --
> Sent from a handheld expect more typos than usual
>

[-- Attachment #2: Type: text/html, Size: 3776 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-21  0:09   ` Warner Losh
@ 2020-09-21  1:05     ` Clem Cole
  2020-09-21  5:55     ` Steve Nickolas
  1 sibling, 0 replies; 44+ messages in thread
From: Clem Cole @ 2020-09-21  1:05 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 3462 bytes --]

Yep.   They all suck.  As Dennis said, “C is quirky” and part of the issue
is HW is even more so.  Clem

On Sun, Sep 20, 2020 at 8:10 PM Warner Losh <imp@bsdimp.com> wrote:

> To two places: stddef.h and stdlib.h :(.
>
> It's interesting to see the different bugs 0, 0L, (char *)0 and (void *)0
> expose or hide as definitions of NULL.
>
> 0 is fine if sizeof(int) == sizeof(void *). Otherwise varadic function
> calls break. 0L is the same, but for long. The pointer definitions run into
> trouble in other contexts since NULL is often incorrectly used as a
> terminating byte in a string instead of '\0'. (void *) has issues with
> const pointers, some of which are relevant if you use it in the wrong
> context.
>
> There were quite spirited debates back in the day for which one was best.
> They all suck. C++ invented a null pointer symbol because it's type rules
> were enough different than C to make a universal NULL #define impossible.
> Is that better or worse? Don't know. It's different.
>
> Glad to see the null-pointer need not have all zero bits being different
> than a 0 constant shall be the null-pointer in sufficient detail.
>
> Warner
>
> On Sun, Sep 20, 2020, 5:54 PM Clem Cole <clemc@ccc.com> wrote:
>
>> Norman NULL has to be defined and I said that/showed it.   The standard
>> says where.  I was not trying to compile NULL without a definition which I
>> agree it not legal.  If that is what Doug was implying I missed understood
>> him but I note NULL was introduced in Typesetter C /V7 where those compiler
>> s set it to 0 in studio but the ANSI/ISO moved it.
>>
>> On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson <norman@oclsc.org> wrote:
>>
>>> Doug McIlroy:
>>>
>>>
>>>
>>>   To put it more strongly. this is not a legal C source file.
>>>
>>>           char *s = NULL;
>>>
>>>   But this is.
>>>
>>>           char *s = 0;
>>>
>>>
>>>
>>> Clem Cole:
>>>
>>>
>>>
>>>    67)The macro NULL is defined in <stddef.h> (and other headers) as a
>>> null
>>>
>>>    pointer constant; see 7.19.
>>>
>>>
>>>
>>> ====
>>>
>>>
>>>
>>> $ cat null.c
>>>
>>> char *s = NULL;
>>>
>>> $ cat zero.c
>>>
>>> char *s = 0;
>>>
>>> $
>>>
>>>
>>>
>>> zero.c is a legal C program.  null.c is not.  Create
>>>
>>> files exactly as shown and compile them if you don't
>>>
>>> believe me.
>>>
>>>
>>>
>>> Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
>>>
>>> to null.c and it becomes legal, but I think that's Doug's
>>>
>>> point: you need an include file.
>>>
>>>
>>>
>>> Personally I prefer to use NULL instead of 0 when spelling
>>>
>>> out a null pointer, because I think it's clearer:
>>>
>>>         if ((buf = malloc(SIZE)) == NULL)
>>>
>>>                 error("dammit andrew");
>>>
>>> though I am willing to omit it when there's no confusion
>>>
>>> about = vs ==:
>>>
>>>         if (*p)
>>>
>>>                 dammit(*p, "andrew");
>>>
>>>
>>>
>>> But that's just a question of style, and Doug's is fine too.
>>>
>>>
>>>
>>> The language does not require the compiler to pre-define
>>>
>>> NULL or to recognize it as a keyword; you have to include
>>>
>>> an appropriate standard header file.
>>>
>>>
>>>
>>> Norman Wilson
>>>
>>> Toronto ON (not 0N nor NULLN)
>>>
>>> --
>> Sent from a handheld expect more typos than usual
>>
>>
>>
>
> --
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 4625 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 23:53 ` Clem Cole
  2020-09-21  0:00   ` Clem Cole
@ 2020-09-21  0:09   ` Warner Losh
  2020-09-21  1:05     ` Clem Cole
  2020-09-21  5:55     ` Steve Nickolas
  1 sibling, 2 replies; 44+ messages in thread
From: Warner Losh @ 2020-09-21  0:09 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]

To two places: stddef.h and stdlib.h :(.

It's interesting to see the different bugs 0, 0L, (char *)0 and (void *)0
expose or hide as definitions of NULL.

0 is fine if sizeof(int) == sizeof(void *). Otherwise varadic function
calls break. 0L is the same, but for long. The pointer definitions run into
trouble in other contexts since NULL is often incorrectly used as a
terminating byte in a string instead of '\0'. (void *) has issues with
const pointers, some of which are relevant if you use it in the wrong
context.

There were quite spirited debates back in the day for which one was best.
They all suck. C++ invented a null pointer symbol because it's type rules
were enough different than C to make a universal NULL #define impossible.
Is that better or worse? Don't know. It's different.

Glad to see the null-pointer need not have all zero bits being different
than a 0 constant shall be the null-pointer in sufficient detail.

Warner

On Sun, Sep 20, 2020, 5:54 PM Clem Cole <clemc@ccc.com> wrote:

> Norman NULL has to be defined and I said that/showed it.   The standard
> says where.  I was not trying to compile NULL without a definition which I
> agree it not legal.  If that is what Doug was implying I missed understood
> him but I note NULL was introduced in Typesetter C /V7 where those compiler
> s set it to 0 in studio but the ANSI/ISO moved it.
>
> On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson <norman@oclsc.org> wrote:
>
>> Doug McIlroy:
>>
>>
>>
>>   To put it more strongly. this is not a legal C source file.
>>
>>           char *s = NULL;
>>
>>   But this is.
>>
>>           char *s = 0;
>>
>>
>>
>> Clem Cole:
>>
>>
>>
>>    67)The macro NULL is defined in <stddef.h> (and other headers) as a
>> null
>>
>>    pointer constant; see 7.19.
>>
>>
>>
>> ====
>>
>>
>>
>> $ cat null.c
>>
>> char *s = NULL;
>>
>> $ cat zero.c
>>
>> char *s = 0;
>>
>> $
>>
>>
>>
>> zero.c is a legal C program.  null.c is not.  Create
>>
>> files exactly as shown and compile them if you don't
>>
>> believe me.
>>
>>
>>
>> Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
>>
>> to null.c and it becomes legal, but I think that's Doug's
>>
>> point: you need an include file.
>>
>>
>>
>> Personally I prefer to use NULL instead of 0 when spelling
>>
>> out a null pointer, because I think it's clearer:
>>
>>         if ((buf = malloc(SIZE)) == NULL)
>>
>>                 error("dammit andrew");
>>
>> though I am willing to omit it when there's no confusion
>>
>> about = vs ==:
>>
>>         if (*p)
>>
>>                 dammit(*p, "andrew");
>>
>>
>>
>> But that's just a question of style, and Doug's is fine too.
>>
>>
>>
>> The language does not require the compiler to pre-define
>>
>> NULL or to recognize it as a keyword; you have to include
>>
>> an appropriate standard header file.
>>
>>
>>
>> Norman Wilson
>>
>> Toronto ON (not 0N nor NULLN)
>>
>> --
> Sent from a handheld expect more typos than usual
>

[-- Attachment #2: Type: text/html, Size: 3993 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 23:53 ` Clem Cole
@ 2020-09-21  0:00   ` Clem Cole
  2020-09-21  2:24     ` John Cowan
  2020-09-21  0:09   ` Warner Losh
  1 sibling, 1 reply; 44+ messages in thread
From: Clem Cole @ 2020-09-21  0:00 UTC (permalink / raw)
  To: Norman Wilson; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

I was also stating (under Henry’s 10th) using a properly defined macro with
the complete cast scheme will be correct and portable to all known
conforming C compilers no matter the target HW architecture — which in a
commercial SW setting is highly valued.

Clem

On Sun, Sep 20, 2020 at 7:53 PM Clem Cole <clemc@ccc.com> wrote:

> Norman NULL has to be defined and I said that/showed it.   The standard
> says where.  I was not trying to compile NULL without a definition which I
> agree it not legal.  If that is what Doug was implying I missed understood
> him but I note NULL was introduced in Typesetter C /V7 where those compiler
> s set it to 0 in studio but the ANSI/ISO moved it.
>
> On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson <norman@oclsc.org> wrote:
>
>> Doug McIlroy:
>>
>>
>>
>>   To put it more strongly. this is not a legal C source file.
>>
>>           char *s = NULL;
>>
>>   But this is.
>>
>>           char *s = 0;
>>
>>
>>
>> Clem Cole:
>>
>>
>>
>>    67)The macro NULL is defined in <stddef.h> (and other headers) as a
>> null
>>
>>    pointer constant; see 7.19.
>>
>>
>>
>> ====
>>
>>
>>
>> $ cat null.c
>>
>> char *s = NULL;
>>
>> $ cat zero.c
>>
>> char *s = 0;
>>
>> $
>>
>>
>>
>> zero.c is a legal C program.  null.c is not.  Create
>>
>> files exactly as shown and compile them if you don't
>>
>> believe me.
>>
>>
>>
>> Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
>>
>> to null.c and it becomes legal, but I think that's Doug's
>>
>> point: you need an include file.
>>
>>
>>
>> Personally I prefer to use NULL instead of 0 when spelling
>>
>> out a null pointer, because I think it's clearer:
>>
>>         if ((buf = malloc(SIZE)) == NULL)
>>
>>                 error("dammit andrew");
>>
>> though I am willing to omit it when there's no confusion
>>
>> about = vs ==:
>>
>>         if (*p)
>>
>>                 dammit(*p, "andrew");
>>
>>
>>
>> But that's just a question of style, and Doug's is fine too.
>>
>>
>>
>> The language does not require the compiler to pre-define
>>
>> NULL or to recognize it as a keyword; you have to include
>>
>> an appropriate standard header file.
>>
>>
>>
>> Norman Wilson
>>
>> Toronto ON (not 0N nor NULLN)
>>
>> --
> Sent from a handheld expect more typos than usual
>
>
> --
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 3214 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 23:00 Norman Wilson
@ 2020-09-20 23:53 ` Clem Cole
  2020-09-21  0:00   ` Clem Cole
  2020-09-21  0:09   ` Warner Losh
  0 siblings, 2 replies; 44+ messages in thread
From: Clem Cole @ 2020-09-20 23:53 UTC (permalink / raw)
  To: Norman Wilson; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

Norman NULL has to be defined and I said that/showed it.   The standard
says where.  I was not trying to compile NULL without a definition which I
agree it not legal.  If that is what Doug was implying I missed understood
him but I note NULL was introduced in Typesetter C /V7 where those compiler
s set it to 0 in studio but the ANSI/ISO moved it.

On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson <norman@oclsc.org> wrote:

> Doug McIlroy:
>
>
>
>   To put it more strongly. this is not a legal C source file.
>
>           char *s = NULL;
>
>   But this is.
>
>           char *s = 0;
>
>
>
> Clem Cole:
>
>
>
>    67)The macro NULL is defined in <stddef.h> (and other headers) as a null
>
>    pointer constant; see 7.19.
>
>
>
> ====
>
>
>
> $ cat null.c
>
> char *s = NULL;
>
> $ cat zero.c
>
> char *s = 0;
>
> $
>
>
>
> zero.c is a legal C program.  null.c is not.  Create
>
> files exactly as shown and compile them if you don't
>
> believe me.
>
>
>
> Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
>
> to null.c and it becomes legal, but I think that's Doug's
>
> point: you need an include file.
>
>
>
> Personally I prefer to use NULL instead of 0 when spelling
>
> out a null pointer, because I think it's clearer:
>
>         if ((buf = malloc(SIZE)) == NULL)
>
>                 error("dammit andrew");
>
> though I am willing to omit it when there's no confusion
>
> about = vs ==:
>
>         if (*p)
>
>                 dammit(*p, "andrew");
>
>
>
> But that's just a question of style, and Doug's is fine too.
>
>
>
> The language does not require the compiler to pre-define
>
> NULL or to recognize it as a keyword; you have to include
>
> an appropriate standard header file.
>
>
>
> Norman Wilson
>
> Toronto ON (not 0N nor NULLN)
>
> --
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 2437 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
@ 2020-09-20 23:00 Norman Wilson
  2020-09-20 23:53 ` Clem Cole
  0 siblings, 1 reply; 44+ messages in thread
From: Norman Wilson @ 2020-09-20 23:00 UTC (permalink / raw)
  To: tuhs

Doug McIlroy:

  To put it more strongly. this is not a legal C source file.
          char *s = NULL;
  But this is.
          char *s = 0;

Clem Cole:

   67)The macro NULL is defined in <stddef.h> (and other headers) as a null
   pointer constant; see 7.19.

====

$ cat null.c
char *s = NULL;
$ cat zero.c
char *s = 0;
$

zero.c is a legal C program.  null.c is not.  Create
files exactly as shown and compile them if you don't
believe me.

Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>)
to null.c and it becomes legal, but I think that's Doug's
point: you need an include file.

Personally I prefer to use NULL instead of 0 when spelling
out a null pointer, because I think it's clearer:
	if ((buf = malloc(SIZE)) == NULL)
		error("dammit andrew");
though I am willing to omit it when there's no confusion
about = vs ==:
	if (*p)
		dammit(*p, "andrew");

But that's just a question of style, and Doug's is fine too.

The language does not require the compiler to pre-define
NULL or to recognize it as a keyword; you have to include
an appropriate standard header file.

Norman Wilson
Toronto ON (not 0N nor NULLN)

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 22:15           ` Clem Cole
@ 2020-09-20 22:47             ` John Cowan
  2020-09-21 20:48               ` Steffen Nurpmeso
  0 siblings, 1 reply; 44+ messages in thread
From: John Cowan @ 2020-09-20 22:47 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

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 <clemc@ccc.com> wrote:

>
>
> On Sun, Sep 20, 2020 at 4:59 PM Steve Nickolas <usotsuki@buric.co> wrote:
>
>> I was under the impression that there was explicitly no requirement that
>> a
>> null pointer be 0,
>>
> Indeed, section 7.19 states it is *implementation-defined*.  See my
> previous message.
>

[-- Attachment #2: Type: text/html, Size: 1867 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 20:58         ` Steve Nickolas
  2020-09-20 21:33           ` Brantley Coile
  2020-09-20 21:35           ` John Cowan
@ 2020-09-20 22:15           ` Clem Cole
  2020-09-20 22:47             ` John Cowan
  2020-09-21 20:46           ` Steffen Nurpmeso
  3 siblings, 1 reply; 44+ messages in thread
From: Clem Cole @ 2020-09-20 22:15 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

[-- Attachment #1: Type: text/plain, Size: 261 bytes --]

On Sun, Sep 20, 2020 at 4:59 PM Steve Nickolas <usotsuki@buric.co> wrote:

> I was under the impression that there was explicitly no requirement that a
> null pointer be 0,
>
Indeed, section 7.19 states it is *implementation-defined*.  See my
previous message.

[-- Attachment #2: Type: text/html, Size: 917 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 20:57         ` Doug McIlroy
@ 2020-09-20 22:13           ` Clem Cole
  2020-09-21 20:43             ` Steffen Nurpmeso
  0 siblings, 1 reply; 44+ messages in thread
From: Clem Cole @ 2020-09-20 22:13 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]

On Sun, Sep 20, 2020 at 4:58 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

>
> To put it more strongly. this is not a legal C source file.
>         char *s = NULL;
> But this is.
>         char *s = 0;
>

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.

: .

[-- Attachment #2: Type: text/html, Size: 6521 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 20:58         ` Steve Nickolas
  2020-09-20 21:33           ` Brantley Coile
@ 2020-09-20 21:35           ` John Cowan
  2020-09-20 22:15           ` Clem Cole
  2020-09-21 20:46           ` Steffen Nurpmeso
  3 siblings, 0 replies; 44+ messages in thread
From: John Cowan @ 2020-09-20 21:35 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: The Eunuchs Hysterical Society, Doug McIlroy

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

When 0 is coerced implicitly or explicitly to a pointer type, it becomes a
null pointer.  That's true even on architectures where all-bits-zero is
*not* a null pointer.  However, in contexts where there is no expected
type, as in a call to execl(), the null at the end of the args list has to
be explicitly cast to (char *)0 or some other null pointer.

As for the definition of NULL, it is indeed 0 on Linux, but can also be
defined as ((void *)0), as on FreeBSD and the Mac, or even as 0L on systems
where ints are half-size and pointers and longs are full-size.

On Sun, Sep 20, 2020 at 4:59 PM Steve Nickolas <usotsuki@buric.co> wrote:

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

[-- Attachment #2: Type: text/html, Size: 2017 bytes --]

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 20:58         ` Steve Nickolas
@ 2020-09-20 21:33           ` Brantley Coile
  2020-10-07  5:43             ` scj
  2020-09-20 21:35           ` John Cowan
                             ` (2 subsequent siblings)
  3 siblings, 1 reply; 44+ messages in thread
From: Brantley Coile @ 2020-09-20 21:33 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: tuhs, Doug McIlroy

The fact that a pointer of zero generates a hardware trap is not defined in the language, whereas a 0 is is defined to be a null pointer. 

I've worked on systems where a 0 pointer could be dereferenced without a trap. I wouldn't recommend it. System designers do things like make the first page of memory invalid so we will get a null pointer trap. On Plan 9 the beginning of the text segment starts at 0x1020.

But that's not part of the C language. The fact that 0 is a null pointer is.

Brantley

> On Sep 20, 2020, at 4:58 PM, Steve Nickolas <usotsuki@buric.co> wrote:
> 
> 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...
> 
> -uso.


^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 20:26       ` Doug McIlroy
  2020-09-20 20:57         ` Doug McIlroy
@ 2020-09-20 20:58         ` Steve Nickolas
  2020-09-20 21:33           ` Brantley Coile
                             ` (3 more replies)
  1 sibling, 4 replies; 44+ messages in thread
From: Steve Nickolas @ 2020-09-20 20:58 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: tuhs

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

-uso.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 20:26       ` Doug McIlroy
@ 2020-09-20 20:57         ` Doug McIlroy
  2020-09-20 22:13           ` Clem Cole
  2020-09-20 20:58         ` Steve Nickolas
  1 sibling, 1 reply; 44+ messages in thread
From: Doug McIlroy @ 2020-09-20 20:57 UTC (permalink / raw)
  To: Will Senn, Steve Nickolas, Doug McIlroy; +Cc: tuhs, doug

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

To put it more strongly. this is not a legal C source file.
        char *s = NULL;
But this is.
        char *s = 0;

Doug

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 20:12     ` Steve Nickolas
@ 2020-09-20 20:26       ` Doug McIlroy
  2020-09-20 20:57         ` Doug McIlroy
  2020-09-20 20:58         ` Steve Nickolas
  2020-09-24  2:25       ` Dave Horsfall
  1 sibling, 2 replies; 44+ messages in thread
From: Doug McIlroy @ 2020-09-20 20:26 UTC (permalink / raw)
  To: Will Senn, Steve Nickolas; +Cc: tuhs, doug

> (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

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 19:28   ` Will Senn
@ 2020-09-20 20:12     ` Steve Nickolas
  2020-09-20 20:26       ` Doug McIlroy
  2020-09-24  2:25       ` Dave Horsfall
  0 siblings, 2 replies; 44+ messages in thread
From: Steve Nickolas @ 2020-09-20 20:12 UTC (permalink / raw)
  To: Will Senn; +Cc: tuhs, doug

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Sun, 20 Sep 2020, Will Senn wrote:

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

My version of that is "while (0!=(entry=getutxevent()))".

(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.)

-uso.

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-20 18:42 ` arnold
@ 2020-09-20 19:28   ` Will Senn
  2020-09-20 20:12     ` Steve Nickolas
  2020-10-07  5:47   ` scj
  1 sibling, 1 reply; 44+ messages in thread
From: Will Senn @ 2020-09-20 19:28 UTC (permalink / raw)
  To: arnold; +Cc: tuhs, doug

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

> On Sep 20, 2020, at 1:42 PM, arnold@skeeve.com wrote:
> 
> Doug McIlroy <doug@cs.dartmouth.edu> wrote:
> 
>> I would like to revive Lorinda Cherry's "parts".
>> Implicit in "revival" is dispelling the hundreds
>> of warnings from  gcc -Wpedantic -Wall -Wextra.
>> Has anybody done this already?
>> 
>> Doug
> 
> I haven't tried this. I do suggest starting with 'gcc -m32' so that
> you're not fighting 64 bit issues at the same time as everything else.
> 
> HTH,
> 
> Arnold

^ permalink raw reply	[flat|nested] 44+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-19  1:51 Doug McIlroy
@ 2020-09-20 18:42 ` arnold
  2020-09-20 19:28   ` Will Senn
  2020-10-07  5:47   ` scj
  0 siblings, 2 replies; 44+ messages in thread
From: arnold @ 2020-09-20 18:42 UTC (permalink / raw)
  To: tuhs, doug

Doug McIlroy <doug@cs.dartmouth.edu> wrote:

> I would like to revive Lorinda Cherry's "parts".
> Implicit in "revival" is dispelling the hundreds
> of warnings from  gcc -Wpedantic -Wall -Wextra.
> Has anybody done this already?
>
> Doug

I haven't tried this. I do suggest starting with 'gcc -m32' so that
you're not fighting 64 bit issues at the same time as everything else.

HTH,

Arnold

^ permalink raw reply	[flat|nested] 44+ messages in thread

* [TUHS] reviving a bit of WWB
@ 2020-09-19  1:51 Doug McIlroy
  2020-09-20 18:42 ` arnold
  0 siblings, 1 reply; 44+ messages in thread
From: Doug McIlroy @ 2020-09-19  1:51 UTC (permalink / raw)
  To: tuhs

I would like to revive Lorinda Cherry's "parts".
Implicit in "revival" is dispelling the hundreds
of warnings from  gcc -Wpedantic -Wall -Wextra.
Has anybody done this already?

Doug

^ permalink raw reply	[flat|nested] 44+ messages in thread

end of thread, other threads:[~2020-10-08  3:09 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-20 22:51 [TUHS] reviving a bit of WWB Norman Wilson
  -- strict thread matches above, loose matches on Subject: below --
2020-09-25 14:19 Doug McIlroy
2020-09-28 17:35 ` Angelo Papenhoff
2020-09-20 23:00 Norman Wilson
2020-09-20 23:53 ` Clem Cole
2020-09-21  0:00   ` Clem Cole
2020-09-21  2:24     ` John Cowan
2020-09-21  0:09   ` Warner Losh
2020-09-21  1:05     ` Clem Cole
2020-09-21  5:55     ` Steve Nickolas
2020-09-21  5:59       ` Warner Losh
2020-09-21 18:40         ` Paul Winalski
2020-09-21 19:56           ` Dan Cross
2020-09-21 20:50       ` John Cowan
2020-09-21 21:22         ` Rob Pike
2020-09-21 21:57           ` Clem Cole
2020-09-21 23:56             ` John Cowan
2020-09-22  0:54               ` Richard Salz
2020-09-21 21:39         ` Steve Nickolas
2020-09-19  1:51 Doug McIlroy
2020-09-20 18:42 ` arnold
2020-09-20 19:28   ` Will Senn
2020-09-20 20:12     ` Steve Nickolas
2020-09-20 20:26       ` Doug McIlroy
2020-09-20 20:57         ` Doug McIlroy
2020-09-20 22:13           ` Clem Cole
2020-09-21 20:43             ` Steffen Nurpmeso
2020-09-20 20:58         ` Steve Nickolas
2020-09-20 21:33           ` Brantley Coile
2020-10-07  5:43             ` scj
2020-09-20 21:35           ` John Cowan
2020-09-20 22:15           ` Clem Cole
2020-09-20 22:47             ` John Cowan
2020-09-21 20:48               ` Steffen Nurpmeso
2020-09-21 20:46           ` Steffen Nurpmeso
2020-09-24  2:25       ` Dave Horsfall
2020-09-24  2:33         ` Clem Cole
2020-09-27  5:54           ` Dave Horsfall
2020-09-24 17:19         ` Paul Winalski
2020-09-24 18:17           ` John Cowan
2020-10-07  5:47   ` scj
2020-10-07  9:20     ` arnold
2020-10-08  0:27     ` Dave Horsfall
2020-10-08  3:08       ` John Cowan

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ http://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git