[TUHS] reviving a bit of WWB

[TUHS] reviving a bit of WWB

[Doug McIlroy]

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

Re: [TUHS] reviving a bit of WWB

[arnold]

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

Re: [TUHS] reviving a bit of WWB

[Will Senn]

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

Re: [TUHS] reviving a bit of WWB

[Steve Nickolas]

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

Re: [TUHS] reviving a bit of WWB

[Doug McIlroy]

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

Re: [TUHS] reviving a bit of WWB

[Doug McIlroy]

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

Re: [TUHS] reviving a bit of WWB

[Steve Nickolas]

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.

Re: [TUHS] reviving a bit of WWB

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

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.

Re: [TUHS] reviving a bit of WWB

[John Cowan]

[-- 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 --]

Re: [TUHS] reviving a bit of WWB

[Clem Cole]

[-- 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 --]

Re: [TUHS] reviving a bit of WWB

[Clem Cole]

[-- 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 --]

Re: [TUHS] reviving a bit of WWB

[John Cowan]

[-- 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 --]

Re: [TUHS] reviving a bit of WWB

[Steffen Nurpmeso]

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)

Re: [TUHS] reviving a bit of WWB

[Steffen Nurpmeso]

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)

Re: [TUHS] reviving a bit of WWB

[Steffen Nurpmeso]

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)

Re: [TUHS] reviving a bit of WWB

[Dave Horsfall]

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

Re: [TUHS] reviving a bit of WWB

[Clem Cole]

[-- 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 --]

Re: [TUHS] reviving a bit of WWB

[Paul Winalski]

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.

Re: [TUHS] reviving a bit of WWB

[John Cowan]

[-- 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 --]

[TUHS] One's complement (was: reviving a bit of WWB)

[Greg 'groggy' Lehey]

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

On Wednesday, 23 September 2020 at 22:33:38 -0400, 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.

I think most of the bigger pre-IBM 360 machines used one's complement.
Didn't the PDP-10?  I knew it not only from the CDC 3200 and 3800, but
primarily from Univac (1108 and 494).  The Univac techies explained to
me that the primary arithmetic function was subtraction; addition was
subtracting the complement.  And that worked faster with one's
complement.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] One's complement (was: reviving a bit of WWB)

[Warner Losh]

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

On Thu, Sep 24, 2020 at 6:20 PM Greg 'groggy' Lehey <grog@lemis.com> wrote:

> On Wednesday, 23 September 2020 at 22:33:38 -0400, 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.
>
> I think most of the bigger pre-IBM 360 machines used one's complement.
> Didn't the PDP-10?  I knew it not only from the CDC 3200 and 3800, but
> primarily from Univac (1108 and 494).  The Univac techies explained to
> me that the primary arithmetic function was subtraction; addition was
> subtracting the complement.  And that worked faster with one's
> complement.
>

Don't know about the others, but I'm pretty sure PDP-10 wasn't 1's
compliment / was 2's compliment..

Warner

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

Re: [TUHS] One's complement (was: reviving a bit of WWB)

[John Cowan]

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

On Thu, Sep 24, 2020 at 8:22 PM Warner Losh <imp@bsdimp.com> wrote:

Don't know about the others, but I'm pretty sure PDP-10 wasn't 1's
>> compliment / was 2's compliment..
>
>
Correct.  The PDP-1 (18 bits) was DEC's 1's complement machine.  Its direct
successors the 4/7/9/15 had both 1's and 2's complement arithmetic.  The
12-bit 5/8/12 machines had only 2's complement, but retained the PDP-4
mnemonic TAD (Two's-complement Add).  By the time the 36-bit 6/10/20 line
was designed, it was clear that 1's complement was history, and the
mnemonic was changed to ADD.

(The PDP-3 was a PDP-1 with a 36-bit data path, and only one ever went into
production; the PDP-2 was to be a 24-bit machine, perhaps a compromise
between 6-bit and 8-bit byte systems, but was never even designed.)



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
I marvel at the creature: so secret and so sly as he is, to come sporting
in the pool before our very window.  Does he think that Men sleep without
watch all night?    --Faramir

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

Re: [TUHS] reviving a bit of WWB

[Dave Horsfall]

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

Re: [TUHS] reviving a bit of WWB

[scj]

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.

Re: [TUHS] reviving a bit of WWB

[scj]

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

Re: [TUHS] reviving a bit of WWB

[arnold]

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

Re: [TUHS] reviving a bit of WWB

[Dave Horsfall]

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

Re: [TUHS] reviving a bit of WWB

[John Cowan]

[-- 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 --]

Re: [TUHS] reviving a bit of WWB

[Greg A. Woods]

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

At Sun, 20 Sep 2020 17:35:52 -0400, John Cowan <cowan@ccil.org> wrote:
Subject: Re: [TUHS] reviving a bit of WWB
>
> 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.

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 <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [TUHS] reviving a bit of WWB

[Larry McVoy]

On Tue, Feb 02, 2021 at 03:08:42PM -0800, Greg A. Woods wrote:
> At Sun, 20 Sep 2020 17:35:52 -0400, John Cowan <cowan@ccil.org> wrote:
> Subject: Re: [TUHS] reviving a bit of WWB
> >
> > 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.
> 
> 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

I've dealt with this, here is a story of a super computer where native
pointers pointed at bits but C pointers pointed at bytes and you can
shake your head at the promotion problems:

https://minnie.tuhs.org/pipermail/tuhs/2017-September/012050.html

Re: [TUHS] reviving a bit of WWB

[Dave Horsfall]

On Tue, 2 Feb 2021, Larry McVoy wrote:

> I've dealt with this, here is a story of a super computer where native 
> pointers pointed at bits but C pointers pointed at bytes and you can 
> shake your head at the promotion problems:
>
> https://minnie.tuhs.org/pipermail/tuhs/2017-September/012050.html

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

Re: [TUHS] reviving a bit of WWB

[Larry McVoy]

On Wed, Feb 03, 2021 at 11:11:44AM +1100, Dave Horsfall wrote:
> On Tue, 2 Feb 2021, Larry McVoy wrote:
> 
> >I've dealt with this, here is a story of a super computer where native
> >pointers pointed at bits but C pointers pointed at bytes and you can shake
> >your head at the promotion problems:
> >
> >https://minnie.tuhs.org/pipermail/tuhs/2017-September/012050.html
> 
> Holy smoking inodes!  I'd forgotten that story...  

I tend to log in to forums these days as "luckydude" and that story is
just the first of many examples.  I have seemed to have gotten lucky
being building up the right experiences and then falling into a job that
can use them.  It really made me look better than I am, things just sort
of flowed.

And having almost 6 months to work on whatever I wanted and deciding to
port the networking stack?  Priceless down the road.  No way they would
have given me that task, I was too green.

Fun times.

Re: [TUHS] reviving a bit of WWB

[Richard Salz]

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

> pointer to a bit

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.

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

Re: [TUHS] reviving a bit of WWB

[Dave Horsfall]

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

On Tue, 2 Feb 2021, Richard Salz wrote:

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

I'm trying to get my head around a 10-bit machine optimised for C... 
Well, if you accept that chars are 10 bits wide then there shouldn't be 
(much of) a problem; just forget about the concept of powers of 2, I 
guess.

Shades of the 60-bit CDC series, as handling strings was a bit of a 
bugger; at least the 12-bit PDP-8 was sort of manageable.

-- Dave

Re: [TUHS] reviving a bit of WWB

[M Douglas McIlroy]

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

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

> On Tue, 2 Feb 2021, Richard Salz wrote:
>
> > 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.
>
> I'm trying to get my head around a 10-bit machine optimised for C...
> Well, if you accept that chars are 10 bits wide then there shouldn't be
> (much of) a problem; just forget about the concept of powers of 2, I
> guess.
>
> Shades of the 60-bit CDC series, as handling strings was a bit of a
> bugger; at least the 12-bit PDP-8 was sort of manageable.
>
> -- Dave

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

Re: [TUHS] reviving a bit of WWB

[Peter Jeremy via TUHS]

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

On 2021-Feb-02 23:32:29 -0500, M Douglas McIlroy <m.douglas.mcilroy@dartmouth.edu> 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?)
>Whirlwind II (built in 1952), was 16 bits. It took a long while for that
>to become common wisdom.

I'm not sure that 16 (or any other 2^n) bits is that obvious up front.
Does anyone know why the computer industry wound up standardising on
8-bit bytes?

Scientific computers were word-based and the number of bits in a word
is more driven by the desired float range/precision.  Commercial
computers needed to support BCD numbers and typically 6-bit characters.
ASCII (when it turned up) was 7 bits and so 8-bit characters wasted
⅛ of the storage.  Minis tended to have shorter word sizes to minimise
the amount of hardware.

-- 
Peter Jeremy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [TUHS] reviving a bit of WWB

[Dave Horsfall]

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

On Wed, 3 Feb 2021, Peter Jeremy wrote:

> I'm not sure that 16 (or any other 2^n) bits is that obvious up front. 
> Does anyone know why the computer industry wound up standardising on 
> 8-bit bytes?

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.

> Scientific computers were word-based and the number of bits in a word is 
> more driven by the desired float range/precision.  Commercial computers 
> needed to support BCD numbers and typically 6-bit characters. ASCII 
> (when it turned up) was 7 bits and so 8-bit characters wasted ⅛ of the 
> storage.  Minis tended to have shorter word sizes to minimise the amount 
> of hardware.

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

Re: [TUHS] reviving a bit of WWB

[Niklas Karlsson]

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

According to Wikipedia:

The first modern, electronic ternary computer, Setun
<https://en.wikipedia.org/wiki/Setun>, was built in 1958 in the Soviet
Union at the Moscow State University
<https://en.wikipedia.org/wiki/Moscow_State_University> by Nikolay
Brusentsov <https://en.wikipedia.org/wiki/Nikolay_Brusentsov>,[4]
<https://en.wikipedia.org/wiki/Ternary_computer#cite_note-cmr-4>[5]
<https://en.wikipedia.org/wiki/Ternary_computer#cite_note-5> and it had
notable advantages over the binary
<https://en.wikipedia.org/wiki/Binary_numeral_system> computers that
eventually replaced it, such as lower electricity consumption and lower
production cost.[4]
<https://en.wikipedia.org/wiki/Ternary_computer#cite_note-cmr-4> In 1970
Brusentsov built an enhanced version of the computer, which he called
Setun-70.[4]
<https://en.wikipedia.org/wiki/Ternary_computer#cite_note-cmr-4> In the
United States, the ternary computing emulator Ternac
<https://en.wikipedia.org/wiki/Ternac> working on a binary machine was
developed in 1973.[6]
<https://en.wikipedia.org/wiki/Ternary_computer#cite_note-comp1974-6>:22

The ternary computer QTC-1 was developed in Canada.[7]
<https://en.wikipedia.org/wiki/Ternary_computer#cite_note-7>
Doesn't seem like they caught on otherwise, though.

Niklas

Den ons 3 feb. 2021 kl 21:10 skrev Dave Horsfall <dave@horsfall.org>:

> On Wed, 3 Feb 2021, Peter Jeremy wrote:
>
> > I'm not sure that 16 (or any other 2^n) bits is that obvious up front.
> > Does anyone know why the computer industry wound up standardising on
> > 8-bit bytes?
>
> 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.
>
> > Scientific computers were word-based and the number of bits in a word is
> > more driven by the desired float range/precision.  Commercial computers
> > needed to support BCD numbers and typically 6-bit characters. ASCII
> > (when it turned up) was 7 bits and so 8-bit characters wasted ⅛ of the
> > storage.  Minis tended to have shorter word sizes to minimise the amount
> > of hardware.
>
> 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

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

Re: [TUHS] reviving a bit of WWB

[Dave Horsfall]

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.

Now that goes back...

-- Dave

Re: [TUHS] reviving a bit of WWB

[M Douglas McIlroy]

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

>> Whirlwind II (built in 1952), was 16 bits. It took a long while for that
>> to become common wisdom.

> Now that goes back...

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 <dave@horsfall.org> 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.
>
> Now that goes back...
>
> -- Dave
>

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

Re: [TUHS] reviving a bit of WWB

[Tom Lyon]

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

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

> On Wed, 3 Feb 2021, Peter Jeremy wrote:
>
> > I'm not sure that 16 (or any other 2^n) bits is that obvious up front.
> > Does anyone know why the computer industry wound up standardising on
> > 8-bit bytes?
>
> 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.
>
> > Scientific computers were word-based and the number of bits in a word is
> > more driven by the desired float range/precision.  Commercial computers
> > needed to support BCD numbers and typically 6-bit characters. ASCII
> > (when it turned up) was 7 bits and so 8-bit characters wasted ⅛ of the
> > storage.  Minis tended to have shorter word sizes to minimise the amount
> > of hardware.
>
> 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



-- 
- Tom

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

Re: [TUHS] One's complement (was: reviving a bit of WWB)

[Ronald Natalie]

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

The DECSystem20 (and the PDP-10 before) were 36 bit two's complement 
machines.  You had to go back to the PDP-1 if you want one's complement 
in the DEC line.    The CDCs and UNIVACs were the only ones that were 
still kicking around in my era.


>>
>>Just to confirm, I pulled out my PDP-10 Hardware Reference Manual; Vol 
>>I - CPU
>>(EK-10/20-HR-001), and it does indeed say (pg. 1-12): "The fixed-point
>>arithmetic instructions use 2's complement representations to do 
>>binary
>>arithmetic." Selah.
>
>Back in school, we had our machine organization course. When we learned 
>about 1's complement, the professor said "I've used a lot of machines 
>that had this. You will likely never see one with it. There are no 
>operational machines on campus with that."It stuck with me. We had a 
>TOPS-20 machine...  the odd turn of phrase was due to a professor that 
>had a board of unknown origin hanging on the wall that was a rumored to 
>be a CDC or similar... ah, the mid 80s...

Warner

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

Re: [TUHS] One's complement (was: reviving a bit of WWB)

[Warner Losh]

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

On Fri, Sep 25, 2020, 9:22 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Warner Losh
>
>     > I'm pretty sure PDP-10 wasn't 1's compliment / was 2's compliment..
>
> Just to confirm, I pulled out my PDP-10 Hardware Reference Manual; Vol I -
> CPU
> (EK-10/20-HR-001), and it does indeed say (pg. 1-12): "The fixed-point
> arithmetic instructions use 2's complement representations to do binary
> arithmetic." Selah.
>

Back in school, we had our machine organization course. When we learned
about 1's complement, the professor said "I've used a lot of machines that
had this. You will likely never see one with it. There are no operational
machines on campus with that." It stuck with me. We had a TOPS-20
machine...  the odd turn of phrase was due to a professor that had a board
of unknown origin hanging on the wall that was a rumored to be a CDC or
similar... ah, the mid 80s...

Warner

>

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

Re: [TUHS] One's complement (was: reviving a bit of WWB)

[Noel Chiappa]

    > From: Warner Losh

    > I'm pretty sure PDP-10 wasn't 1's compliment / was 2's compliment..

Just to confirm, I pulled out my PDP-10 Hardware Reference Manual; Vol I - CPU
(EK-10/20-HR-001), and it does indeed say (pg. 1-12): "The fixed-point
arithmetic instructions use 2's complement representations to do binary
arithmetic." Selah.

	     Noel