The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] reviving a bit of WWB
@ 2020-09-19  1:51 Doug McIlroy
  2020-09-20 18:42 ` arnold
  0 siblings, 1 reply; 31+ 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] 31+ messages in thread

* Re: [TUHS] reviving a bit of WWB
  2020-09-19  1:51 [TUHS] reviving a bit of WWB 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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-25  0:18           ` [TUHS] One's complement (was: reviving a bit of WWB) Greg 'groggy' Lehey
  2020-09-27  5:54           ` [TUHS] reviving a bit of WWB Dave Horsfall
  2020-09-24 17:19         ` Paul Winalski
  1 sibling, 2 replies; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ messages in thread

* [TUHS] One's complement (was: reviving a bit of WWB)
  2020-09-24  2:33         ` Clem Cole
@ 2020-09-25  0:18           ` Greg 'groggy' Lehey
  2020-09-25  0:22             ` Warner Losh
  2020-09-27  5:54           ` [TUHS] reviving a bit of WWB Dave Horsfall
  1 sibling, 1 reply; 31+ messages in thread
From: Greg 'groggy' Lehey @ 2020-09-25  0:18 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society

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

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

* Re: [TUHS] One's complement (was: reviving a bit of WWB)
  2020-09-25  0:18           ` [TUHS] One's complement (was: reviving a bit of WWB) Greg 'groggy' Lehey
@ 2020-09-25  0:22             ` Warner Losh
  2020-09-25  1:39               ` John Cowan
  0 siblings, 1 reply; 31+ messages in thread
From: Warner Losh @ 2020-09-25  0:22 UTC (permalink / raw)
  To: Greg 'groggy' Lehey; +Cc: The Eunuchs Hysterical Society

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

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

* Re: [TUHS] One's complement (was: reviving a bit of WWB)
  2020-09-25  0:22             ` Warner Losh
@ 2020-09-25  1:39               ` John Cowan
  0 siblings, 0 replies; 31+ messages in thread
From: John Cowan @ 2020-09-25  1:39 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

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

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

* Re: [TUHS] reviving a bit of WWB
  2020-09-24  2:33         ` Clem Cole
  2020-09-25  0:18           ` [TUHS] One's complement (was: reviving a bit of WWB) Greg 'groggy' Lehey
@ 2020-09-27  5:54           ` Dave Horsfall
  1 sibling, 0 replies; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ 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; 31+ 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] 31+ messages in thread

* Re: [TUHS] One's complement (was: reviving a bit of WWB)
  2020-09-25 15:30 ` Warner Losh
@ 2020-09-25 16:10   ` Ronald Natalie
  0 siblings, 0 replies; 31+ messages in thread
From: Ronald Natalie @ 2020-09-25 16:10 UTC (permalink / raw)
  To: Warner Losh, Noel Chiappa; +Cc: The Eunuchs Hysterical Society

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

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

* Re: [TUHS] One's complement (was: reviving a bit of WWB)
  2020-09-25 15:21 [TUHS] One's complement (was: reviving a bit of WWB) Noel Chiappa
@ 2020-09-25 15:30 ` Warner Losh
  2020-09-25 16:10   ` Ronald Natalie
  0 siblings, 1 reply; 31+ messages in thread
From: Warner Losh @ 2020-09-25 15:30 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: The Eunuchs Hysterical Society

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

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

* Re: [TUHS] One's complement (was: reviving a bit of WWB)
@ 2020-09-25 15:21 Noel Chiappa
  2020-09-25 15:30 ` Warner Losh
  0 siblings, 1 reply; 31+ messages in thread
From: Noel Chiappa @ 2020-09-25 15:21 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > 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


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

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

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-19  1:51 [TUHS] reviving a bit of WWB 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-25  0:18           ` [TUHS] One's complement (was: reviving a bit of WWB) Greg 'groggy' Lehey
2020-09-25  0:22             ` Warner Losh
2020-09-25  1:39               ` John Cowan
2020-09-27  5:54           ` [TUHS] reviving a bit of WWB 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
2020-09-25 15:21 [TUHS] One's complement (was: reviving a bit of WWB) Noel Chiappa
2020-09-25 15:30 ` Warner Losh
2020-09-25 16:10   ` Ronald Natalie

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