The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] v7 K&R C
@ 2020-04-25  1:59 Adam Thornton
  2020-04-25  2:37 ` Charles Anthony
  0 siblings, 1 reply; 65+ messages in thread
From: Adam Thornton @ 2020-04-25  1:59 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

The C in v7 is, canonically, the language described in K&R, right?

I must be doing something dumb.

I am getting Webb Miller’s “s” editor built there, and I am down to one function.

/* chop_arg - chop a function's argument to a maximum length */
static chop_arg(fcn, arg, maxlen)
int (*fcn)();
int maxlen;
char *arg;
{
    char save;

    save = arg[maxlen];
    arg[maxlen] = '\0';
    fcn(arg);
    arg[maxlen] = save;
}

This doesn’t like the function pointer.

$ cc -c choparg.c
choparg.c:11: Call of non-function

So, uh, what is the obvious thing I am missing?  How am I supposed to be passing function pointers in the C compiler that comes with v7?

Adam

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

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

* Re: [TUHS] v7 K&R C
  2020-04-25  1:59 [TUHS] v7 K&R C Adam Thornton
@ 2020-04-25  2:37 ` Charles Anthony
  2020-04-25  2:47   ` Adam Thornton
  2020-04-25  2:50   ` Adam Thornton
  0 siblings, 2 replies; 65+ messages in thread
From: Charles Anthony @ 2020-04-25  2:37 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

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

On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com> wrote:

> This doesn’t like the function pointer.
>

> $ cc -c choparg.c
> choparg.c:11: Call of non-function
>
> Perhaps:

    (*fcn)(arg);

-- Charles

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

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

* Re: [TUHS] v7 K&R C
  2020-04-25  2:37 ` Charles Anthony
@ 2020-04-25  2:47   ` Adam Thornton
  2020-04-25  2:51     ` Rob Pike
  2020-04-25  2:50   ` Adam Thornton
  1 sibling, 1 reply; 65+ messages in thread
From: Adam Thornton @ 2020-04-25  2:47 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society; +Cc: ak

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



> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com> wrote:
> 
> 
> 
> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com <mailto:athornton@gmail.com>> wrote:
> This doesn’t like the function pointer.
> 
> $ cc -c choparg.c
> choparg.c:11: Call of non-function
> 
> Perhaps:
> 
>     (*fcn)(arg);
> 

We have a winner!

Also, Kartik, dunno where it is on the net, but if you install a v7 system, /usr/src/cmd/c

Adam


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

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

* Re: [TUHS] v7 K&R C
  2020-04-25  2:37 ` Charles Anthony
  2020-04-25  2:47   ` Adam Thornton
@ 2020-04-25  2:50   ` Adam Thornton
  2020-04-25  5:59     ` Lars Brinkhoff
  1 sibling, 1 reply; 65+ messages in thread
From: Adam Thornton @ 2020-04-25  2:50 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

Getting closer!

$ cc -c s *.o
$ ./s Makefile
./s: cannot execute
$ ls -l s
-rw-rw-r-- 1 dmr     61644 Apr 23 11:06 s
$ chmod +x s
$ ./s
usage: s file
$ ./s Makefile
Memory fault - core dumped

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

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

* Re: [TUHS] v7 K&R C
  2020-04-25  2:47   ` Adam Thornton
@ 2020-04-25  2:51     ` Rob Pike
  2020-04-25  2:54       ` Rob Pike
                         ` (2 more replies)
  0 siblings, 3 replies; 65+ messages in thread
From: Rob Pike @ 2020-04-25  2:51 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society, ak

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

The ability to call a function pointer fp with the syntax fp() rather than
(*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
sure it was not in v7 C, as you observe.

Convenient though the shorthand may be, it always bothered me as
inconsistent and misleading. (I am pretty sure I used it sometimes
regardless.)

-rob


On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com> wrote:

>
>
> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com>
> wrote:
>
>
>
> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com> wrote:
>
>> This doesn’t like the function pointer.
>>
>
>> $ cc -c choparg.c
>> choparg.c:11: Call of non-function
>>
>> Perhaps:
>
>     (*fcn)(arg);
>
>
> We have a winner!
>
> Also, Kartik, dunno where it is on the net, but if you install a v7
> system, /usr/src/cmd/c
>
> Adam
>
>

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

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

* Re: [TUHS] v7 K&R C
  2020-04-25  2:51     ` Rob Pike
@ 2020-04-25  2:54       ` Rob Pike
  2020-04-25  3:04         ` Larry McVoy
  2020-05-11  0:28         ` scj
  2020-04-25  3:37       ` Dave Horsfall
  2020-04-27 13:19       ` Tony Finch
  2 siblings, 2 replies; 65+ messages in thread
From: Rob Pike @ 2020-04-25  2:54 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society, ak

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

Another debate at the time was caused by a disagreement between pcc and cc
regarding enums: are they a type or just a way to declare constant? I
remember getting annoyed by pcc not letting me declare a constant with an
enum and use it as an int. I protested to scj and dmr and after some to-ing
and fro-ing Steve changed pcc to treat them as constants.

Not sure it was the right decision, but C desperately wanted a non-macro
way to define a constant. I'd probably argue the same way today. The real
lesson is how propinquity affects progress.

-rbo


On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com> wrote:

> The ability to call a function pointer fp with the syntax fp() rather than
> (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
> sure it was not in v7 C, as you observe.
>
> Convenient though the shorthand may be, it always bothered me as
> inconsistent and misleading. (I am pretty sure I used it sometimes
> regardless.)
>
> -rob
>
>
> On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com>
> wrote:
>
>>
>>
>> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com>
>> wrote:
>>
>>
>>
>> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com>
>> wrote:
>>
>>> This doesn’t like the function pointer.
>>>
>>
>>> $ cc -c choparg.c
>>> choparg.c:11: Call of non-function
>>>
>>> Perhaps:
>>
>>     (*fcn)(arg);
>>
>>
>> We have a winner!
>>
>> Also, Kartik, dunno where it is on the net, but if you install a v7
>> system, /usr/src/cmd/c
>>
>> Adam
>>
>>

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

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

* Re: [TUHS] v7 K&R C
  2020-04-25  2:54       ` Rob Pike
@ 2020-04-25  3:04         ` Larry McVoy
  2020-04-25  3:30           ` Clem Cole
  2020-05-11  0:28         ` scj
  1 sibling, 1 reply; 65+ messages in thread
From: Larry McVoy @ 2020-04-25  3:04 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society, ak

I hate enums.  I thought they would be type checked and they are just ints.
I love C but enums suck.

On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote:
> Another debate at the time was caused by a disagreement between pcc and cc
> regarding enums: are they a type or just a way to declare constant? I
> remember getting annoyed by pcc not letting me declare a constant with an
> enum and use it as an int. I protested to scj and dmr and after some to-ing
> and fro-ing Steve changed pcc to treat them as constants.
> 
> Not sure it was the right decision, but C desperately wanted a non-macro
> way to define a constant. I'd probably argue the same way today. The real
> lesson is how propinquity affects progress.
> 
> -rbo
> 
> 
> On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com> wrote:
> 
> > The ability to call a function pointer fp with the syntax fp() rather than
> > (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
> > sure it was not in v7 C, as you observe.
> >
> > Convenient though the shorthand may be, it always bothered me as
> > inconsistent and misleading. (I am pretty sure I used it sometimes
> > regardless.)
> >
> > -rob
> >
> >
> > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com>
> >> wrote:
> >>
> >>
> >>
> >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com>
> >> wrote:
> >>
> >>> This doesn???t like the function pointer.
> >>>
> >>
> >>> $ cc -c choparg.c
> >>> choparg.c:11: Call of non-function
> >>>
> >>> Perhaps:
> >>
> >>     (*fcn)(arg);
> >>
> >>
> >> We have a winner!
> >>
> >> Also, Kartik, dunno where it is on the net, but if you install a v7
> >> system, /usr/src/cmd/c
> >>
> >> Adam
> >>
> >>

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

* Re: [TUHS] v7 K&R C
  2020-04-25  3:04         ` Larry McVoy
@ 2020-04-25  3:30           ` Clem Cole
  2020-04-25  3:43             ` Larry McVoy
  2020-04-25 13:17             ` Dan Cross
  0 siblings, 2 replies; 65+ messages in thread
From: Clem Cole @ 2020-04-25  3:30 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society, ak

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

Amen bro.  I always felt that they got added because pascal had something
that C didn’t, and yet it really was not the same.  I always felt they were
a feature that was only partly implemented and if they were not going  to
be fully typed then just leave them out and use cpp like we had always done
before.

On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy <lm@mcvoy.com> wrote:

> I hate enums.  I thought they would be type checked and they are just ints.
> I love C but enums suck.
>
> On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote:
> > Another debate at the time was caused by a disagreement between pcc and
> cc
> > regarding enums: are they a type or just a way to declare constant? I
> > remember getting annoyed by pcc not letting me declare a constant with an
> > enum and use it as an int. I protested to scj and dmr and after some
> to-ing
> > and fro-ing Steve changed pcc to treat them as constants.
> >
> > Not sure it was the right decision, but C desperately wanted a non-macro
> > way to define a constant. I'd probably argue the same way today. The real
> > lesson is how propinquity affects progress.
> >
> > -rbo
> >
> >
> > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com> wrote:
> >
> > > The ability to call a function pointer fp with the syntax fp() rather
> than
> > > (*fp)() came rather late, I think at Bjarne's suggestion or example.
> Pretty
> > > sure it was not in v7 C, as you observe.
> > >
> > > Convenient though the shorthand may be, it always bothered me as
> > > inconsistent and misleading. (I am pretty sure I used it sometimes
> > > regardless.)
> > >
> > > -rob
> > >
> > >
> > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com>
> > > wrote:
> > >
> > >>
> > >>
> > >> On Apr 24, 2020, at 7:37 PM, Charles Anthony <
> charles.unix.pro@gmail.com>
> > >> wrote:
> > >>
> > >>
> > >>
> > >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com>
> > >> wrote:
> > >>
> > >>> This doesn???t like the function pointer.
> > >>>
> > >>
> > >>> $ cc -c choparg.c
> > >>> choparg.c:11: Call of non-function
> > >>>
> > >>> Perhaps:
> > >>
> > >>     (*fcn)(arg);
> > >>
> > >>
> > >> We have a winner!
> > >>
> > >> Also, Kartik, dunno where it is on the net, but if you install a v7
> > >> system, /usr/src/cmd/c
> > >>
> > >> Adam
> > >>
> > >>
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-- 
Sent from a handheld expect more typos than usual

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

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

* Re: [TUHS] v7 K&R C
  2020-04-25  2:51     ` Rob Pike
  2020-04-25  2:54       ` Rob Pike
@ 2020-04-25  3:37       ` Dave Horsfall
  2020-04-27 13:19       ` Tony Finch
  2 siblings, 0 replies; 65+ messages in thread
From: Dave Horsfall @ 2020-04-25  3:37 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

On Sat, 25 Apr 2020, Rob Pike wrote:

> The ability to call a function pointer fp with the syntax fp() rather 
> than (*fp)() came rather late, I think at Bjarne's suggestion or 
> example. Pretty sure it was not in v7 C, as you observe.

I have never seen that syntax used (and I've been tooling around with Unix 
for decades).  The variable "fp" in an argument list is a pointer to the 
function, not the function itself, so dereference it.

I wouldn't put it past Stroustrup to have it in C++ though, as it pretty 
much has everything else in it.

> Convenient though the shorthand may be, it always bothered me as 
> inconsistent and misleading. (I am pretty sure I used it sometimes 
> regardless.)

Indeed...  My principle is to write code as though the next person to 
maintain it is a psychopathic axe-murderer who knows where you live (or 
perhaps even yourself, a year later)...

-- Dave

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

* Re: [TUHS] v7 K&R C
  2020-04-25  3:30           ` Clem Cole
@ 2020-04-25  3:43             ` Larry McVoy
  2020-04-25  3:54               ` Jon Steinhart
  2020-04-25 13:17             ` Dan Cross
  1 sibling, 1 reply; 65+ messages in thread
From: Larry McVoy @ 2020-04-25  3:43 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society, ak

What Clem said, that is precisely how I feel.  I'd be fully for them if they
fully type checked but without that, yeah, cpp is fine, enums are just a
distraction.


On Fri, Apr 24, 2020 at 11:30:26PM -0400, Clem Cole wrote:
> Amen bro.  I always felt that they got added because pascal had something
> that C didn???t, and yet it really was not the same.  I always felt they were
> a feature that was only partly implemented and if they were not going  to
> be fully typed then just leave them out and use cpp like we had always done
> before.
> 
> On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy <lm@mcvoy.com> wrote:
> 
> > I hate enums.  I thought they would be type checked and they are just ints.
> > I love C but enums suck.
> >
> > On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote:
> > > Another debate at the time was caused by a disagreement between pcc and
> > cc
> > > regarding enums: are they a type or just a way to declare constant? I
> > > remember getting annoyed by pcc not letting me declare a constant with an
> > > enum and use it as an int. I protested to scj and dmr and after some
> > to-ing
> > > and fro-ing Steve changed pcc to treat them as constants.
> > >
> > > Not sure it was the right decision, but C desperately wanted a non-macro
> > > way to define a constant. I'd probably argue the same way today. The real
> > > lesson is how propinquity affects progress.
> > >
> > > -rbo
> > >
> > >
> > > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com> wrote:
> > >
> > > > The ability to call a function pointer fp with the syntax fp() rather
> > than
> > > > (*fp)() came rather late, I think at Bjarne's suggestion or example.
> > Pretty
> > > > sure it was not in v7 C, as you observe.
> > > >
> > > > Convenient though the shorthand may be, it always bothered me as
> > > > inconsistent and misleading. (I am pretty sure I used it sometimes
> > > > regardless.)
> > > >
> > > > -rob
> > > >
> > > >
> > > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com>
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >> On Apr 24, 2020, at 7:37 PM, Charles Anthony <
> > charles.unix.pro@gmail.com>
> > > >> wrote:
> > > >>
> > > >>
> > > >>
> > > >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> This doesn???t like the function pointer.
> > > >>>
> > > >>
> > > >>> $ cc -c choparg.c
> > > >>> choparg.c:11: Call of non-function
> > > >>>
> > > >>> Perhaps:
> > > >>
> > > >>     (*fcn)(arg);
> > > >>
> > > >>
> > > >> We have a winner!
> > > >>
> > > >> Also, Kartik, dunno where it is on the net, but if you install a v7
> > > >> system, /usr/src/cmd/c
> > > >>
> > > >> Adam
> > > >>
> > > >>
> >
> > --
> > ---
> > Larry McVoy                  lm at mcvoy.com
> > http://www.mcvoy.com/lm
> >
> -- 
> Sent from a handheld expect more typos than usual

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

* Re: [TUHS] v7 K&R C
  2020-04-25  3:43             ` Larry McVoy
@ 2020-04-25  3:54               ` Jon Steinhart
  2020-04-25 11:44                 ` Michael Kjörling
  0 siblings, 1 reply; 65+ messages in thread
From: Jon Steinhart @ 2020-04-25  3:54 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Larry McVoy writes:
> What Clem said, that is precisely how I feel.  I'd be fully for them if they
> fully type checked but without that, yeah, cpp is fine, enums are just a
> distraction.

Enums are implemented badly, but it's possible to do even worse.  This is from
linux /usr/include/sys/mount.h - can anyone explain the point of it to me?

enum
{
  MS_RDONLY = 1,		/* Mount read-only.  */
#define MS_RDONLY	MS_RDONLY
  MS_NOSUID = 2,		/* Ignore suid and sgid bits.  */
#define MS_NOSUID	MS_NOSUID
  MS_NODEV = 4,			/* Disallow access to device special files.  */
#define MS_NODEV	MS_NODEV
  MS_NOEXEC = 8,		/* Disallow program execution.  */
#define MS_NOEXEC	MS_NOEXEC
  MS_SYNCHRONOUS = 16,		/* Writes are synced at once.  */
#define MS_SYNCHRONOUS	MS_SYNCHRONOUS
  MS_REMOUNT = 32,		/* Alter flags of a mounted FS.  */
#define MS_REMOUNT	MS_REMOUNT
  MS_MANDLOCK = 64,		/* Allow mandatory locks on an FS.  */
#define MS_MANDLOCK	MS_MANDLOCK
  MS_DIRSYNC = 128,		/* Directory modifications are synchronous.  */
#define MS_DIRSYNC	MS_DIRSYNC
  MS_NOATIME = 1024,		/* Do not update access times.  */
#define MS_NOATIME	MS_NOATIME
  MS_NODIRATIME = 2048,		/* Do not update directory access times.  */
#define MS_NODIRATIME	MS_NODIRATIME
  MS_BIND = 4096,		/* Bind directory at different place.  */
#define MS_BIND		MS_BIND
  MS_MOVE = 8192,
#define MS_MOVE		MS_MOVE
  MS_REC = 16384,
#define MS_REC		MS_REC
  MS_SILENT = 32768,
#define MS_SILENT	MS_SILENT
  MS_POSIXACL = 1 << 16,	/* VFS does not apply the umask.  */
#define MS_POSIXACL	MS_POSIXACL
  MS_UNBINDABLE = 1 << 17,	/* Change to unbindable.  */
#define MS_UNBINDABLE	MS_UNBINDABLE
  MS_PRIVATE = 1 << 18,		/* Change to private.  */
#define MS_PRIVATE	MS_PRIVATE
  MS_SLAVE = 1 << 19,		/* Change to slave.  */
#define MS_SLAVE	MS_SLAVE
  MS_SHARED = 1 << 20,		/* Change to shared.  */
#define MS_SHARED	MS_SHARED
  MS_RELATIME = 1 << 21,	/* Update atime relative to mtime/ctime.  */
#define MS_RELATIME	MS_RELATIME
  MS_KERNMOUNT = 1 << 22,	/* This is a kern_mount call.  */
#define MS_KERNMOUNT	MS_KERNMOUNT
  MS_I_VERSION =  1 << 23,	/* Update inode I_version field.  */
#define MS_I_VERSION	MS_I_VERSION
  MS_STRICTATIME = 1 << 24,	/* Always perform atime updates.  */
#define MS_STRICTATIME	MS_STRICTATIME
  MS_LAZYTIME = 1 << 25,	/* Update the on-disk [acm]times lazily.  */
#define MS_LAZYTIME	MS_LAZYTIME
  MS_ACTIVE = 1 << 30,
#define MS_ACTIVE	MS_ACTIVE
  MS_NOUSER = 1 << 31
#define MS_NOUSER	MS_NOUSER
};

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

* Re: [TUHS] v7 K&R C
  2020-04-25  2:50   ` Adam Thornton
@ 2020-04-25  5:59     ` Lars Brinkhoff
  0 siblings, 0 replies; 65+ messages in thread
From: Lars Brinkhoff @ 2020-04-25  5:59 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

Adam Thornton wrote:
> Getting closer!
>
> $ cc -c s *.o
> $ ./s Makefile
> ./s: cannot execute

-c says to make an object file, right?  Try -o instead.

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

* Re: [TUHS] v7 K&R C
  2020-04-25  3:54               ` Jon Steinhart
@ 2020-04-25 11:44                 ` Michael Kjörling
  0 siblings, 0 replies; 65+ messages in thread
From: Michael Kjörling @ 2020-04-25 11:44 UTC (permalink / raw)
  To: tuhs

On 24 Apr 2020 20:54 -0700, from jon@fourwinds.com (Jon Steinhart):
> Enums are implemented badly, but it's possible to do even worse.  This is from
> linux /usr/include/sys/mount.h - can anyone explain the point of it to me?
> 
> enum
> {
>   MS_RDONLY = 1,		/* Mount read-only.  */
> #define MS_RDONLY	MS_RDONLY
>   MS_NOSUID = 2,		/* Ignore suid and sgid bits.  */
> #define MS_NOSUID	MS_NOSUID

If you mean the #defining to itself, check out the discussion starting
at <https://minnie.tuhs.org/pipermail/tuhs/2019-November/019429.html>.

If you have the archive locally, that's Message-ID
<201911131802.xADI2fxE752068@darkstar.fourwinds.com> from 13 Nov 2019
10:02 -0800 / 18:02 UTC.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


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

* Re: [TUHS] v7 K&R C
  2020-04-25  3:30           ` Clem Cole
  2020-04-25  3:43             ` Larry McVoy
@ 2020-04-25 13:17             ` Dan Cross
  1 sibling, 0 replies; 65+ messages in thread
From: Dan Cross @ 2020-04-25 13:17 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society, ak

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

On Fri, Apr 24, 2020 at 11:31 PM Clem Cole <clemc@ccc.com> wrote:

> Amen bro.  I always felt that they got added because pascal had something
> that C didn’t, and yet it really was not the same.  I always felt they were
> a feature that was only partly implemented and if they were not going  to
> be fully typed then just leave them out and use cpp like we had always done
> before.
>

Aww shucks; I actually kinda like enums. When creating sequentially
numbered constants, they're convenient.

That said, the typing issues I have a lot of sympathy for. For true
constants, it's a shame that `const` didn't make it in earlier, though we
have it now. Abusing enum to define constants certainly feels like, well,
abuse.

        - Dan C.


On Fri, Apr 24, 2020 at 11:05 PM Larry McVoy <lm@mcvoy.com> wrote:
>
>> I hate enums.  I thought they would be type checked and they are just
>> ints.
>> I love C but enums suck.
>>
>> On Sat, Apr 25, 2020 at 12:54:27PM +1000, Rob Pike wrote:
>> > Another debate at the time was caused by a disagreement between pcc and
>> cc
>> > regarding enums: are they a type or just a way to declare constant? I
>> > remember getting annoyed by pcc not letting me declare a constant with
>> an
>> > enum and use it as an int. I protested to scj and dmr and after some
>> to-ing
>> > and fro-ing Steve changed pcc to treat them as constants.
>> >
>> > Not sure it was the right decision, but C desperately wanted a non-macro
>> > way to define a constant. I'd probably argue the same way today. The
>> real
>> > lesson is how propinquity affects progress.
>> >
>> > -rbo
>> >
>> >
>> > On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com> wrote:
>> >
>> > > The ability to call a function pointer fp with the syntax fp() rather
>> than
>> > > (*fp)() came rather late, I think at Bjarne's suggestion or example.
>> Pretty
>> > > sure it was not in v7 C, as you observe.
>> > >
>> > > Convenient though the shorthand may be, it always bothered me as
>> > > inconsistent and misleading. (I am pretty sure I used it sometimes
>> > > regardless.)
>> > >
>> > > -rob
>> > >
>> > >
>> > > On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com>
>> > > wrote:
>> > >
>> > >>
>> > >>
>> > >> On Apr 24, 2020, at 7:37 PM, Charles Anthony <
>> charles.unix.pro@gmail.com>
>> > >> wrote:
>> > >>
>> > >>
>> > >>
>> > >> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com>
>> > >> wrote:
>> > >>
>> > >>> This doesn???t like the function pointer.
>> > >>>
>> > >>
>> > >>> $ cc -c choparg.c
>> > >>> choparg.c:11: Call of non-function
>> > >>>
>> > >>> Perhaps:
>> > >>
>> > >>     (*fcn)(arg);
>> > >>
>> > >>
>> > >> We have a winner!
>> > >>
>> > >> Also, Kartik, dunno where it is on the net, but if you install a v7
>> > >> system, /usr/src/cmd/c
>> > >>
>> > >> Adam
>> > >>
>> > >>
>>
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com
>> http://www.mcvoy.com/lm
>>
> --
> Sent from a handheld expect more typos than usual
>

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

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

* Re: [TUHS] v7 K&R C
  2020-04-25  2:51     ` Rob Pike
  2020-04-25  2:54       ` Rob Pike
  2020-04-25  3:37       ` Dave Horsfall
@ 2020-04-27 13:19       ` Tony Finch
  2 siblings, 0 replies; 65+ messages in thread
From: Tony Finch @ 2020-04-27 13:19 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Rob Pike <robpike@gmail.com> wrote:

> The ability to call a function pointer fp with the syntax fp() rather than
> (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
> sure it was not in v7 C, as you observe.

I've seen some interesting discussion about Dave Horsfall's favourite
retro-C definition of abort():

	int abort 4;
	...
		abort();

https://minnie.tuhs.org/pipermail/tuhs/2020-March/020680.html

In particular a lot of people didn't know that function pointers could not
be called like abort() so they didn't realise that 4 was the machine code
contents of the function, not the address of the function. (Extra
confusing since branching to address 4 was also a plausible way to crash
the program...)

But that made me wonder what 7th-and-earlier C would do if you tried to
call a local variable. I guess that would lead to the compiler saying

		error("Call of non-function");

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Hebrides, Bailey, Fair Isle, Faeroes: Northeasterly 4 to 6, occasionally 7 at
first in north Fair Isle. Moderate or rough. Showers. Good, occasionally
moderate.

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

* Re: [TUHS] v7 K&R C
  2020-04-25  2:54       ` Rob Pike
  2020-04-25  3:04         ` Larry McVoy
@ 2020-05-11  0:28         ` scj
  2020-05-11  0:32           ` Rob Pike
                             ` (2 more replies)
  1 sibling, 3 replies; 65+ messages in thread
From: scj @ 2020-05-11  0:28 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society, ak

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

Following up on Rob's comment, I always took the point of view that
Dennis owned the C description, and what he said goes.  Not that I
didn't make suggestions that he accepted.  One of the better ones
(actually in B) was ^ for exclusive OR.  One of the worse ones was the
syntax for casts.  We looked at about 5 different ideas and hated all of
them.   And most of them couldn't be easily compiled with Yacc.  So I
took the grammar for declarations, removed the variable name, and voila,
it expressed everything we wanted in the way of semantics, had a simple
rule of construction, and we badly needed the functionality for the
Interdata port.   I quickly came to hate it, though -- the casts we were
using looked like a teletype threw up in the middle of the code. 

With respect to enums, there is a feature I've wanted for years: a typed
typedef.  Saying typetdef int foo would make foo an integer, but if you
passed an ordinary int to something declared as foo it would be an
error.  Even if it was an integer constant unless cast. 

The amount of mechanism required to get that behavior from both C and
C++ is horrible, so far as I know, although C++ has accreted so much
stuff maybe it's there now... 

Steve

---

On 2020-04-24 19:54, Rob Pike wrote:

> Another debate at the time was caused by a disagreement between pcc and cc regarding enums: are they a type or just a way to declare constant? I remember getting annoyed by pcc not letting me declare a constant with an enum and use it as an int. I protested to scj and dmr and after some to-ing and fro-ing Steve changed pcc to treat them as constants. 
> 
> Not sure it was the right decision, but C desperately wanted a non-macro way to define a constant. I'd probably argue the same way today. The real lesson is how propinquity affects progress. 
> 
> -rbo 
> 
> On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com> wrote: 
> The ability to call a function pointer fp with the syntax fp() rather than (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty sure it was not in v7 C, as you observe. 
> 
> Convenient though the shorthand may be, it always bothered me as inconsistent and misleading. (I am pretty sure I used it sometimes regardless.)
> 
> -rob 
> 
> On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com> wrote: 
> 
> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com> wrote: 
> 
> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com> wrote: 
> This doesn't like the function pointer. 
> 
> $ cc -c choparg.c 
> choparg.c:11: Call of non-function 
> 
> Perhaps: 
> 
> (*fcn)(arg);

We have a winner! 

Also, Kartik, dunno where it is on the net, but if you install a v7
system, /usr/src/cmd/c 

Adam

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

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

* Re: [TUHS] v7 K&R C
  2020-05-11  0:28         ` scj
@ 2020-05-11  0:32           ` Rob Pike
  2020-05-11  0:57             ` Larry McVoy
  2020-05-11  2:08           ` Lawrence Stewart
  2020-05-11 11:36           ` Michael Kjörling
  2 siblings, 1 reply; 65+ messages in thread
From: Rob Pike @ 2020-05-11  0:32 UTC (permalink / raw)
  To: Steve Johnson; +Cc: The Eunuchs Hysterical Society, ak

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

Interesting that Go had only what you call "typed typdefs" until we needed
to add "untyped typedefs" so we could provide aliasing for forwarding
declarations. And that necessity made me unhappy. But the short version: Go
went the other way with what "typedef" means.

-rob


On Mon, May 11, 2020 at 10:28 AM <scj@yaccman.com> wrote:

> Following up on Rob's comment, I always took the point of view that Dennis
> owned the C description, and what he said goes.  Not that I didn't make
> suggestions that he accepted.  One of the better ones (actually in B) was ^
> for exclusive OR.  One of the worse ones was the syntax for casts.  We
> looked at about 5 different ideas and hated all of them.   And most of them
> couldn't be easily compiled with Yacc.  So I took the grammar for
> declarations, removed the variable name, and voila, it expressed everything
> we wanted in the way of semantics, had a simple rule of construction, and
> we badly needed the functionality for the Interdata port.   I quickly came
> to hate it, though -- the casts we were using looked like a teletype threw
> up in the middle of the code.
>
> With respect to enums, there is a feature I've wanted for years: a typed
> typedef.  Saying typetdef int foo would make foo an integer, but if you
> passed an ordinary int to something declared as foo it would be an error.
> Even if it was an integer constant unless cast.
>
> The amount of mechanism required to get that behavior from both C and C++
> is horrible, so far as I know, although C++ has accreted so much stuff
> maybe it's there now...
>
> Steve
> ---
>
>
>
> On 2020-04-24 19:54, Rob Pike wrote:
>
> Another debate at the time was caused by a disagreement between pcc and cc
> regarding enums: are they a type or just a way to declare constant? I
> remember getting annoyed by pcc not letting me declare a constant with an
> enum and use it as an int. I protested to scj and dmr and after some to-ing
> and fro-ing Steve changed pcc to treat them as constants.
>
> Not sure it was the right decision, but C desperately wanted a non-macro
> way to define a constant. I'd probably argue the same way today. The real
> lesson is how propinquity affects progress.
>
> -rbo
>
>
> On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com> wrote:
>
> The ability to call a function pointer fp with the syntax fp() rather than
> (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
> sure it was not in v7 C, as you observe.
>
> Convenient though the shorthand may be, it always bothered me as
> inconsistent and misleading. (I am pretty sure I used it sometimes
> regardless.)
>
> -rob
>
>
> On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com>
> wrote:
>
>
>
> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com>
> wrote:
>
>
>
> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com> wrote:
>
> This doesn't like the function pointer.
>
>
> $ cc -c choparg.c
> choparg.c:11: Call of non-function
>
>
> Perhaps:
>
>     (*fcn)(arg);
>
>
> We have a winner!
>
> Also, Kartik, dunno where it is on the net, but if you install a v7
> system, /usr/src/cmd/c
>
> Adam
>
>

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

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

* Re: [TUHS] v7 K&R C
  2020-05-11  0:32           ` Rob Pike
@ 2020-05-11  0:57             ` Larry McVoy
  2020-05-11 17:32               ` Greg A. Woods
  0 siblings, 1 reply; 65+ messages in thread
From: Larry McVoy @ 2020-05-11  0:57 UTC (permalink / raw)
  To: Rob Pike; +Cc: The Eunuchs Hysterical Society, ak

My mail is screwed up, I see Rob's reply to Steve but didn't see Steve's
original.

> On Mon, May 11, 2020 at 10:28 AM <scj@yaccman.com> wrote:
> > With respect to enums, there is a feature I've wanted for years: a typed
> > typedef.  Saying typetdef int foo would make foo an integer, but if you
> > passed an ordinary int to something declared as foo it would be an error.
> > Even if it was an integer constant unless cast.

Steve, I couldn't agree more, you are 100% right, this is how it should
work.  I wanted to like enums because I naively thought they'd have these
semantics but then learned they really aren't any different than a well
managed list of #defines.

IMHO, without your semantics, enums are pretty useless, #define is good
enough and more clear.

--lm

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

* Re: [TUHS] v7 K&R C
  2020-05-11  0:28         ` scj
  2020-05-11  0:32           ` Rob Pike
@ 2020-05-11  2:08           ` Lawrence Stewart
  2020-05-11 11:36           ` Michael Kjörling
  2 siblings, 0 replies; 65+ messages in thread
From: Lawrence Stewart @ 2020-05-11  2:08 UTC (permalink / raw)
  To: Steve Johnson; +Cc: The Eunuchs Hysterical Society, ak

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

If I remember correctly, enums in Mesa (the PARC Pascal like system language) had typed enums.
The 1979 version of the language manual at http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf <http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf>
says so anyway.
-L

PS  The niftiest use of #define I know about was at the short lived supercomputer company SiCortex around 2005.  Wilson Snyder (verilator fame) wrote a thing that extracted all the constants and register definitions from the CPU chip spec and output them as #define equivalents in 5 different languages.

PPS Thank you for ‘^'

> On 2020, May 10, at 8:28 PM, scj@yaccman.com wrote:
> 
> Following up on Rob's comment, I always took the point of view that Dennis owned the C description, and what he said goes.  Not that I didn't make suggestions that he accepted.  One of the better ones (actually in B) was ^ for exclusive OR.  One of the worse ones was the syntax for casts.  We looked at about 5 different ideas and hated all of them.   And most of them couldn't be easily compiled with Yacc.  So I took the grammar for declarations, removed the variable name, and voila, it expressed everything we wanted in the way of semantics, had a simple rule of construction, and we badly needed the functionality for the Interdata port.   I quickly came to hate it, though -- the casts we were using looked like a teletype threw up in the middle of the code.
> 
> With respect to enums, there is a feature I've wanted for years: a typed typedef.  Saying typetdef int foo would make foo an integer, but if you passed an ordinary int to something declared as foo it would be an error.  Even if it was an integer constant unless cast.
> 
> The amount of mechanism required to get that behavior from both C and C++ is horrible, so far as I know, although C++ has accreted so much stuff maybe it's there now...
> 
> Steve
> 
> ---
>  
> 
> 
> On 2020-04-24 19:54, Rob Pike wrote:
> 
>> Another debate at the time was caused by a disagreement between pcc and cc regarding enums: are they a type or just a way to declare constant? I remember getting annoyed by pcc not letting me declare a constant with an enum and use it as an int. I protested to scj and dmr and after some to-ing and fro-ing Steve changed pcc to treat them as constants.
>>  
>> Not sure it was the right decision, but C desperately wanted a non-macro way to define a constant. I'd probably argue the same way today. The real lesson is how propinquity affects progress.
>>  
>> -rbo
>>  
>> 
>> On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike@gmail.com <mailto:robpike@gmail.com>> wrote:
>> The ability to call a function pointer fp with the syntax fp() rather than (*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty sure it was not in v7 C, as you observe.
>>  
>> Convenient though the shorthand may be, it always bothered me as inconsistent and misleading. (I am pretty sure I used it sometimes regardless.)
>>  
>> -rob
>>  
>> 
>> On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton@gmail.com <mailto:athornton@gmail.com>> wrote:
>> 
>> 
>>> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro@gmail.com <mailto:charles.unix.pro@gmail.com>> wrote:
>>> 
>>>  
>>> 
>>> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton@gmail.com <mailto:athornton@gmail.com>> wrote:
>>> This doesn't like the function pointer.
>>>  
>>> $ cc -c choparg.c
>>> choparg.c:11: Call of non-function
>>>  
>>> Perhaps:
>>>  
>>>     (*fcn)(arg);
>>>  
>> 
>> We have a winner!
>>  
>> Also, Kartik, dunno where it is on the net, but if you install a v7 system, /usr/src/cmd/c
>>  
>> Adam


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

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

* Re: [TUHS] v7 K&R C
  2020-05-11  0:28         ` scj
  2020-05-11  0:32           ` Rob Pike
  2020-05-11  2:08           ` Lawrence Stewart
@ 2020-05-11 11:36           ` Michael Kjörling
  2 siblings, 0 replies; 65+ messages in thread
From: Michael Kjörling @ 2020-05-11 11:36 UTC (permalink / raw)
  To: tuhs

On 10 May 2020 17:28 -0700, from scj@yaccman.com:
> With respect to enums, there is a feature I've wanted for years: a typed
> typedef.  Saying typetdef int foo would make foo an integer, but if you
> passed an ordinary int to something declared as foo it would be an
> error.  Even if it was an integer constant unless cast.

Isn't that at least pretty close to how Ada does it?

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


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

* Re: [TUHS] v7 K&R C
  2020-05-11  0:57             ` Larry McVoy
@ 2020-05-11 17:32               ` Greg A. Woods
  2020-05-11 18:25                 ` Paul Winalski
  0 siblings, 1 reply; 65+ messages in thread
From: Greg A. Woods @ 2020-05-11 17:32 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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

At Sun, 10 May 2020 17:57:46 -0700, Larry McVoy <lm@mcvoy.com> wrote:
Subject: Re: [TUHS] v7 K&R C
>
> > On Mon, May 11, 2020 at 10:28 AM <scj@yaccman.com> wrote:
> > > With respect to enums, there is a feature I've wanted for years: a typed
> > > typedef.  Saying typetdef int foo would make foo an integer, but if you
> > > passed an ordinary int to something declared as foo it would be an error.
> > > Even if it was an integer constant unless cast.
>
> Steve, I couldn't agree more, you are 100% right, this is how it should
> work.  I wanted to like enums because I naively thought they'd have these
> semantics but then learned they really aren't any different than a well
> managed list of #defines.

Absolutely agreed!

The lameness of typedef (and in how enum is related to typedef) is one
of the saddest parts of C.  (The other is the default promotion to int.)

It would be trivial to fix too -- for a "new" C, that is.  Making it
backward compatible for legacy code would be tough, even with tooling to
help fix the worst issues.  I've seen far too much code that would be
hard to fix by hand, e.g. some that even goes so far as to assume things
like arithmetic on enum values will produce other valid enum values.

Ideally enums could be a value in any native type, including float/double.

> IMHO, without your semantics, enums are pretty useless, #define is good
> enough and more clear.

Actually that's no longer true with a good modern toolchain, especially
with respect to the debugger.  A good debugger can now show the enum
symbol for a (matching) value of a properly typedefed variable.

(In fact I never thouth that a #define macro was more clear, even before
debugger support -- the debugger support just gave me a better excuse to
use to explain my preference!)

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

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

* Re: [TUHS] v7 K&R C
  2020-05-11 17:32               ` Greg A. Woods
@ 2020-05-11 18:25                 ` Paul Winalski
  2020-05-11 18:37                   ` Clem Cole
  2020-05-11 18:37                   ` Larry McVoy
  0 siblings, 2 replies; 65+ messages in thread
From: Paul Winalski @ 2020-05-11 18:25 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

On 5/11/20, Greg A. Woods <woods@robohack.ca> wrote:
>
> The lameness of typedef (and in how enum is related to typedef) is one
> of the saddest parts of C.  (The other is the default promotion to int.)

I would add a third:  file-scope declarations being global by default.
One must use the keyword "static" to restrict a file-scope declaration
to the file it's declared in.  And why "static"?  All file-scope
declarations have static allocation.  Why isn't the keyword "local" or
"own"?  Anyway, the way it ought to be is that file-scope declarations
are restricted to the file they're declared in.  To make the symbol
visible outside its file, you should have to explicitly say "global".

> It would be trivial to fix too -- for a "new" C, that is.  Making it
> backward compatible for legacy code would be tough, even with tooling to
> help fix the worst issues.  I've seen far too much code that would be
> hard to fix by hand, e.g. some that even goes so far as to assume things
> like arithmetic on enum values will produce other valid enum values.

This ought to be easy to fix using a compiler command line option for
the legacy behavior.  Many C compilers do this already to support K&R
semantics vs. standard C semantics.

> Ideally enums could be a value in any native type, including float/double.

Except pointers, of course.

>> IMHO, without your semantics, enums are pretty useless, #define is good
>> enough and more clear.
>
> Actually that's no longer true with a good modern toolchain, especially
> with respect to the debugger.  A good debugger can now show the enum
> symbol for a (matching) value of a properly typedefed variable.

Indeed.

-Paul W.

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

* Re: [TUHS] v7 K&R C
  2020-05-11 18:25                 ` Paul Winalski
@ 2020-05-11 18:37                   ` Clem Cole
  2020-05-11 19:12                     ` Paul Winalski
  2020-05-11 18:37                   ` Larry McVoy
  1 sibling, 1 reply; 65+ messages in thread
From: Clem Cole @ 2020-05-11 18:37 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Unix Heritage Society mailing list

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

On Mon, May 11, 2020 at 2:25 PM Paul Winalski <paul.winalski@gmail.com>
wrote:

> This ought to be easy to fix using a compiler command line option for
> the legacy behavior.  Many C compilers do this already to support K&R
> semantics vs. standard C semantics.
>
Hrrrumph

Point taken but ...

C++ is an example in my mind of not listening to Dennis' words:

   - “C is quirky, flawed, and an enormous success.”
   <https://www.inspiringquotes.us/quotes/2Rki_bGM7zqTA>
   - “When I read commentary about suggestions for where C should go, I
   often think back and give thanks that it wasn't developed under the advice
   of a worldwide crowd.”
   <https://www.inspiringquotes.us/quotes/eDQR_hqwtHAC9>
   - “A language that doesn't have everything is actually easier to program
   in than some that do”
   <https://www.inspiringquotes.us/quotes/R86z_ybYw9JTS>

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

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

* Re: [TUHS] v7 K&R C
  2020-05-11 18:25                 ` Paul Winalski
  2020-05-11 18:37                   ` Clem Cole
@ 2020-05-11 18:37                   ` Larry McVoy
  1 sibling, 0 replies; 65+ messages in thread
From: Larry McVoy @ 2020-05-11 18:37 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Unix Heritage Society mailing list

On Mon, May 11, 2020 at 02:25:15PM -0400, Paul Winalski wrote:
> On 5/11/20, Greg A. Woods <woods@robohack.ca> wrote:
> >
> > The lameness of typedef (and in how enum is related to typedef) is one
> > of the saddest parts of C.  (The other is the default promotion to int.)
> 
> I would add a third:  file-scope declarations being global by default.
> One must use the keyword "static" to restrict a file-scope declaration
> to the file it's declared in.  And why "static"?  All file-scope

I never cared for "static" either, seemed weird.  All my code is

#define	private	static

private int
super_duper(void)
{
...
}

and everyone knows what that means at a glance.

> declarations have static allocation.  Why isn't the keyword "local" or
> "own"?  Anyway, the way it ought to be is that file-scope declarations
> are restricted to the file they're declared in.  To make the symbol
> visible outside its file, you should have to explicitly say "global".
> 
> > It would be trivial to fix too -- for a "new" C, that is.  Making it
> > backward compatible for legacy code would be tough, even with tooling to
> > help fix the worst issues.  I've seen far too much code that would be
> > hard to fix by hand, e.g. some that even goes so far as to assume things
> > like arithmetic on enum values will produce other valid enum values.
> 
> This ought to be easy to fix using a compiler command line option for
> the legacy behavior.  Many C compilers do this already to support K&R
> semantics vs. standard C semantics.
> 
> > Ideally enums could be a value in any native type, including float/double.
> 
> Except pointers, of course.
> 
> >> IMHO, without your semantics, enums are pretty useless, #define is good
> >> enough and more clear.
> >
> > Actually that's no longer true with a good modern toolchain, especially
> > with respect to the debugger.  A good debugger can now show the enum
> > symbol for a (matching) value of a properly typedefed variable.
> 
> Indeed.
> 
> -Paul W.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

* Re: [TUHS] v7 K&R C
  2020-05-11 18:37                   ` Clem Cole
@ 2020-05-11 19:12                     ` Paul Winalski
  2020-05-11 19:57                       ` joe mcguckin
  0 siblings, 1 reply; 65+ messages in thread
From: Paul Winalski @ 2020-05-11 19:12 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Unix Heritage Society mailing list

On 5/11/20, Clem Cole <clemc@ccc.com> wrote:
>
> C++ is an example in my mind of not listening to Dennis' words:
>
>    - “C is quirky, flawed, and an enormous success.”

Ditto Fortran.

>    - “When I read commentary about suggestions for where C should go, I
>    often think back and give thanks that it wasn't developed under the
> advice
>    of a worldwide crowd.”

The old saying of an elephant being a mouse designed by committee comes to mind.

Language standards committees tend to be like a pack of dogs
contemplating a tree.  Each dog isn't satisfied with the tree until
he's peed on it.

>    - “A language that doesn't have everything is actually easier to program
>    in than some that do”

Big, comprehensive languages such as PL/I, Ada, and C++ tend to have
more of their share of toxic language features--things that shouldn't
be used if you want reliable, easily maintained and understood code.
Ada failed for two reasons:  [1] it had cooties because of its
military origins, and [2] it collapsed under the weight of all of its
features.

-Paul W.

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

* Re: [TUHS] v7 K&R C
  2020-05-11 19:12                     ` Paul Winalski
@ 2020-05-11 19:57                       ` joe mcguckin
  2020-05-11 20:25                         ` Larry McVoy
  0 siblings, 1 reply; 65+ messages in thread
From: joe mcguckin @ 2020-05-11 19:57 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Unix Heritage Society mailing list

Maybe it’s time for C++ subset ‘G'


Joe McGuckin
ViaNet Communications

joe@via.net
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



> On May 11, 2020, at 12:12 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> On 5/11/20, Clem Cole <clemc@ccc.com> wrote:
>> 
>> C++ is an example in my mind of not listening to Dennis' words:
>> 
>>   - “C is quirky, flawed, and an enormous success.”
> 
> Ditto Fortran.
> 
>>   - “When I read commentary about suggestions for where C should go, I
>>   often think back and give thanks that it wasn't developed under the
>> advice
>>   of a worldwide crowd.”
> 
> The old saying of an elephant being a mouse designed by committee comes to mind.
> 
> Language standards committees tend to be like a pack of dogs
> contemplating a tree.  Each dog isn't satisfied with the tree until
> he's peed on it.
> 
>>   - “A language that doesn't have everything is actually easier to program
>>   in than some that do”
> 
> Big, comprehensive languages such as PL/I, Ada, and C++ tend to have
> more of their share of toxic language features--things that shouldn't
> be used if you want reliable, easily maintained and understood code.
> Ada failed for two reasons:  [1] it had cooties because of its
> military origins, and [2] it collapsed under the weight of all of its
> features.
> 
> -Paul W.


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

* Re: [TUHS] v7 K&R C
  2020-05-11 19:57                       ` joe mcguckin
@ 2020-05-11 20:25                         ` Larry McVoy
  2020-05-12 17:23                           ` Paul Winalski
  0 siblings, 1 reply; 65+ messages in thread
From: Larry McVoy @ 2020-05-11 20:25 UTC (permalink / raw)
  To: joe mcguckin; +Cc: The Unix Heritage Society mailing list

Isn't that effectively what companies do now?  Don't they all have a
"Here is what you can use, this and nothing else" doc?

On Mon, May 11, 2020 at 12:57:01PM -0700, joe mcguckin wrote:
> Maybe it???s time for C++ subset ???G'
> 
> 
> Joe McGuckin
> ViaNet Communications
> 
> joe@via.net
> 650-207-0372 cell
> 650-213-1302 office
> 650-969-2124 fax
> 
> 
> 
> > On May 11, 2020, at 12:12 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
> > 
> > On 5/11/20, Clem Cole <clemc@ccc.com> wrote:
> >> 
> >> C++ is an example in my mind of not listening to Dennis' words:
> >> 
> >>   - ???C is quirky, flawed, and an enormous success.???
> > 
> > Ditto Fortran.
> > 
> >>   - ???When I read commentary about suggestions for where C should go, I
> >>   often think back and give thanks that it wasn't developed under the
> >> advice
> >>   of a worldwide crowd.???
> > 
> > The old saying of an elephant being a mouse designed by committee comes to mind.
> > 
> > Language standards committees tend to be like a pack of dogs
> > contemplating a tree.  Each dog isn't satisfied with the tree until
> > he's peed on it.
> > 
> >>   - ???A language that doesn't have everything is actually easier to program
> >>   in than some that do???
> > 
> > Big, comprehensive languages such as PL/I, Ada, and C++ tend to have
> > more of their share of toxic language features--things that shouldn't
> > be used if you want reliable, easily maintained and understood code.
> > Ada failed for two reasons:  [1] it had cooties because of its
> > military origins, and [2] it collapsed under the weight of all of its
> > features.
> > 
> > -Paul W.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

* Re: [TUHS] v7 K&R C
  2020-05-11 20:25                         ` Larry McVoy
@ 2020-05-12 17:23                           ` Paul Winalski
  2020-05-12 17:35                             ` ron
  2020-05-13 23:36                             ` Dave Horsfall
  0 siblings, 2 replies; 65+ messages in thread
From: Paul Winalski @ 2020-05-12 17:23 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Unix Heritage Society mailing list

On 5/11/20, Larry McVoy <lm@mcvoy.com> wrote:
> Isn't that effectively what companies do now?  Don't they all have a
> "Here is what you can use, this and nothing else" doc?
>
> On Mon, May 11, 2020 at 12:57:01PM -0700, joe mcguckin wrote:
>> Maybe it???s time for C++ subset ???G'

Absolutely.  The projects that I ran effectively used C++ as a
stronger-typed version of C.  A small subset of C++ features were
allowed, but among the prohibited features were:

o multiple inheritance
o operator overloading
o friend classes
o C++ exception handling
o all std:: and STL functions

The last two of these are mainly for performance reasons.  throw and
catch play merry hell with compiler optimizations, especially of
global variables.

-Paul W.

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

* Re: [TUHS] v7 K&R C
  2020-05-12 17:23                           ` Paul Winalski
@ 2020-05-12 17:35                             ` ron
  2020-05-12 17:42                               ` Larry McVoy
  2020-05-12 18:36                               ` Paul Winalski
  2020-05-13 23:36                             ` Dave Horsfall
  1 sibling, 2 replies; 65+ messages in thread
From: ron @ 2020-05-12 17:35 UTC (permalink / raw)
  To: Paul Winalski; +Cc: The Unix Heritage Society mailing list

> On 5/11/20, Larry McVoy <lm@mcvoy.com> wrote:

> o all std:: and STL functions
>
> The last two of these are mainly for performance reasons.  throw and
> catch play merry hell with compiler optimizations, especially of
> global variables.

You'll have to explain to me how templates or the standard library (which
by the way includes all of the C stuff) affects performance.   In fact, we
use templates to INCREASE rather than decrease performance.    Templating
is almost entirely compile time rewrites.


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

* Re: [TUHS] v7 K&R C
  2020-05-12 17:35                             ` ron
@ 2020-05-12 17:42                               ` Larry McVoy
  2020-05-12 18:36                               ` Paul Winalski
  1 sibling, 0 replies; 65+ messages in thread
From: Larry McVoy @ 2020-05-12 17:42 UTC (permalink / raw)
  To: ron; +Cc: The Unix Heritage Society mailing list

Just a note, you seemed like you are replying to me (see below) but what
you quoted Paul wrote.  I am most certainly NOT putting myself out there
as a C++ expert, I'm a C guy through and through.

On Tue, May 12, 2020 at 01:35:24PM -0400, ron@ronnatalie.com wrote:
> > On 5/11/20, Larry McVoy <lm@mcvoy.com> wrote:
> 
> > o all std:: and STL functions
> >
> > The last two of these are mainly for performance reasons.  throw and
> > catch play merry hell with compiler optimizations, especially of
> > global variables.
> 
> You'll have to explain to me how templates or the standard library (which
> by the way includes all of the C stuff) affects performance.   In fact, we
> use templates to INCREASE rather than decrease performance.    Templating
> is almost entirely compile time rewrites.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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

* Re: [TUHS] v7 K&R C
  2020-05-12 17:35                             ` ron
  2020-05-12 17:42                               ` Larry McVoy
@ 2020-05-12 18:36                               ` Paul Winalski
  1 sibling, 0 replies; 65+ messages in thread
From: Paul Winalski @ 2020-05-12 18:36 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

On 5/12/20, ron@ronnatalie.com <ron@ronnatalie.com> wrote:
>> On 5/11/20, Larry McVoy <lm@mcvoy.com> wrote:
>
>> o all std:: and STL functions
>>
>> The last two of these are mainly for performance reasons.  throw and
>> catch play merry hell with compiler optimizations, especially of
>> global variables.
>
> You'll have to explain to me how templates or the standard library (which
> by the way includes all of the C stuff) affects performance.   In fact, we
> use templates to INCREASE rather than decrease performance.    Templating
> is almost entirely compile time rewrites.

The C++ standard libraries make heavy use of throw/catch exception
handling.  If routine A calls routine B, and B is known by the
compiler to have the capability to throw exceptions, a bunch of
important optimizations can't be done.  For example:

o You can't keep global values in registers around the call to B
because the handler that catches an exception that B throws might use
that global variable.  So you have to spill the value around the call.

o You can't do value propagation of global variables around the call
to B because a handler might change their values.

And it gets a lot worse when you start doing parallel loop execution.
I implemented a new design for exception handling in a C/C++ compiler
back end, and I found lots of corner cases where the C++ standard was
silent as to what should happen when exceptions are thrown or caught
from parallel threads.  Things such as the order of execution of
constructors and destructors for parallel routines when a thrown
exception is unwound, and which side of the parallelization executes
constructors and destructors under those conditions.  The committee
just plain never considered those issues.

-Paul W.

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

* Re: [TUHS] v7 K&R C
  2020-05-12 17:23                           ` Paul Winalski
  2020-05-12 17:35                             ` ron
@ 2020-05-13 23:36                             ` Dave Horsfall
  2020-05-14  0:42                               ` John P. Linderman
                                                 ` (2 more replies)
  1 sibling, 3 replies; 65+ messages in thread
From: Dave Horsfall @ 2020-05-13 23:36 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Tue, 12 May 2020, Paul Winalski wrote:

> Absolutely.  The projects that I ran effectively used C++ as a 
> stronger-typed version of C.  A small subset of C++ features were 
> allowed, but among the prohibited features were:

[...]

> o operator overloading

[...]

I never could figure out why Stroustrup implemented that "feature"; let's 
see, this operator usually means this, except when you use it in that 
situation in which case it means something else.  Now, try debugging that.

I had to learn C++ for a project at $WORK years ago (the client demanded 
it), and boy was I glad when I left...

-- Dave

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

* Re: [TUHS] v7 K&R C
  2020-05-13 23:36                             ` Dave Horsfall
@ 2020-05-14  0:42                               ` John P. Linderman
  2020-05-14  2:44                                 ` Rich Morin
  2020-05-14 17:21                                 ` Larry McVoy
  2020-05-14  4:21                               ` Greg A. Woods
  2020-05-14 17:32                               ` Larry McVoy
  2 siblings, 2 replies; 65+ messages in thread
From: John P. Linderman @ 2020-05-14  0:42 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

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

I never liked call by reference. When I was trying to understand a chunk of
code, it was a great mental simplification to know that whatever a called
routine did, it couldn't have an effect on the code I was trying to
understand except through a returned value and (ghastly) global variables.
Operator overloading is far worse. Now I can't even be sure code I'm
looking at is doing what I thought it did.

On Wed, May 13, 2020 at 7:38 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Tue, 12 May 2020, Paul Winalski wrote:
>
> > Absolutely.  The projects that I ran effectively used C++ as a
> > stronger-typed version of C.  A small subset of C++ features were
> > allowed, but among the prohibited features were:
>
> [...]
>
> > o operator overloading
>
> [...]
>
> I never could figure out why Stroustrup implemented that "feature"; let's
> see, this operator usually means this, except when you use it in that
> situation in which case it means something else.  Now, try debugging that.
>
> I had to learn C++ for a project at $WORK years ago (the client demanded
> it), and boy was I glad when I left...
>
> -- Dave
>

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

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

* Re: [TUHS] v7 K&R C
  2020-05-14  0:42                               ` John P. Linderman
@ 2020-05-14  2:44                                 ` Rich Morin
  2020-05-14  3:09                                   ` Charles Anthony
                                                     ` (2 more replies)
  2020-05-14 17:21                                 ` Larry McVoy
  1 sibling, 3 replies; 65+ messages in thread
From: Rich Morin @ 2020-05-14  2:44 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

> On May 13, 2020, at 17:42, John P. Linderman <jpl.jpl@gmail.com> wrote:
> 
> I never liked call by reference. When I was trying to understand a chunk of code, it was a great mental simplification to know that whatever a called routine did, it couldn't have an effect on the code I was trying to understand except through a returned value and (ghastly) global variables. ...

A Fortran implementation I used years ago kept constants in a "literal pool".  So, if you called a subroutine, passing in a constant, there was a possibility that the constant might be modified upon the routine's return.  I don't recall this ever causing a problem in practice, but the possibility was amusing...

-r


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

* Re: [TUHS] v7 K&R C
  2020-05-14  2:44                                 ` Rich Morin
@ 2020-05-14  3:09                                   ` Charles Anthony
  2020-05-14 12:27                                     ` ron
                                                       ` (2 more replies)
  2020-05-14  7:38                                   ` Dave Horsfall
  2020-05-14 17:13                                   ` Paul Winalski
  2 siblings, 3 replies; 65+ messages in thread
From: Charles Anthony @ 2020-05-14  3:09 UTC (permalink / raw)
  To: Rich Morin; +Cc: The Eunuchs Hysterical Society

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

On Wed, May 13, 2020 at 7:45 PM Rich Morin <rdm@cfcl.com> wrote:

> > On May 13, 2020, at 17:42, John P. Linderman <jpl.jpl@gmail.com> wrote:
> >
> > I never liked call by reference. When I was trying to understand a chunk
> of code, it was a great mental simplification to know that whatever a
> called routine did, it couldn't have an effect on the code I was trying to
> understand except through a returned value and (ghastly) global variables.
> ...
>
> A Fortran implementation I used years ago kept constants in a "literal
> pool".  So, if you called a subroutine, passing in a constant, there was a
> possibility that the constant might be modified upon the routine's return.
> I don't recall this ever causing a problem in practice, but the possibility
> was amusing...
>



Ah yes.  A long time ago, some one came to me with a mysteriously behaving
Pr1me FORTRAN program; after much head scratching, I found where they were
changing the value of "0".

 -- Charles

>
> --
X-Clacks-Overhead: GNU Terry Pratchett

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

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

* Re: [TUHS] v7 K&R C
  2020-05-13 23:36                             ` Dave Horsfall
  2020-05-14  0:42                               ` John P. Linderman
@ 2020-05-14  4:21                               ` Greg A. Woods
  2020-05-14  4:40                                 ` Warner Losh
  2020-05-14 17:32                               ` Larry McVoy
  2 siblings, 1 reply; 65+ messages in thread
From: Greg A. Woods @ 2020-05-14  4:21 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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

At Thu, 14 May 2020 09:36:57 +1000 (EST), Dave Horsfall <dave@horsfall.org> wrote:
Subject: Re: [TUHS] v7 K&R C
>
> On Tue, 12 May 2020, Paul Winalski wrote:
>
> > o operator overloading
>
> [...]
>
> I never could figure out why Stroustrup implemented that "feature";
> let's see, this operator usually means this, except when you use it in
> that situation in which case it means something else.  Now, try
> debugging that.

Well in the true OO world the ability to "overload" a message (aka what
is sometimes effectively an operator) allows a wise designer to apply
the traditional meaning of that message (operator) to a new kind of
object.  Attempts to change the meaning of a message (operator) when
applied to already well known objects is forbidden by good taste and
sane reviewers.

C++ being a bit of a dog's breakfast seems to have given some people the
idea that they can get away with abusing operator overloading for what
can only amount to obfuscation.

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

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

* Re: [TUHS] v7 K&R C
  2020-05-14  4:21                               ` Greg A. Woods
@ 2020-05-14  4:40                                 ` Warner Losh
  0 siblings, 0 replies; 65+ messages in thread
From: Warner Losh @ 2020-05-14  4:40 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

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

On Wed, May 13, 2020, 10:22 PM Greg A. Woods <woods@robohack.ca> wrote:

> At Thu, 14 May 2020 09:36:57 +1000 (EST), Dave Horsfall <dave@horsfall.org>
> wrote:
> Subject: Re: [TUHS] v7 K&R C
> >
> > On Tue, 12 May 2020, Paul Winalski wrote:
> >
> > > o operator overloading
> >
> > [...]
> >
> > I never could figure out why Stroustrup implemented that "feature";
> > let's see, this operator usually means this, except when you use it in
> > that situation in which case it means something else.  Now, try
> > debugging that.
>
> Well in the true OO world the ability to "overload" a message (aka what
> is sometimes effectively an operator) allows a wise designer to apply
> the traditional meaning of that message (operator) to a new kind of
> object.  Attempts to change the meaning of a message (operator) when
> applied to already well known objects is forbidden by good taste and
> sane reviewers.
>
> C++ being a bit of a dog's breakfast seems to have given some people the
> idea that they can get away with abusing operator overloading for what
> can only amount to obfuscation.
>

Queue rant about << and >> overloading...

Warner

--
>                                         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: Type: text/html, Size: 2518 bytes --]

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

* Re: [TUHS] v7 K&R C
  2020-05-14  2:44                                 ` Rich Morin
  2020-05-14  3:09                                   ` Charles Anthony
@ 2020-05-14  7:38                                   ` Dave Horsfall
  2020-05-14 12:25                                     ` ron
  2020-05-14 17:13                                   ` Paul Winalski
  2 siblings, 1 reply; 65+ messages in thread
From: Dave Horsfall @ 2020-05-14  7:38 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Wed, 13 May 2020, Rich Morin wrote:

> A Fortran implementation I used years ago kept constants in a "literal 
> pool".  So, if you called a subroutine, passing in a constant, there was 
> a possibility that the constant might be modified upon the routine's 
> return.  I don't recall this ever causing a problem in practice, but the 
> possibility was amusing...

As I dimly recall, Fortran has always used call by value/result (or 
whatever the term is).  So, if you modify an argument that happened to be 
passed as a constant...

-- Dave

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

* Re: [TUHS] v7 K&R C
  2020-05-14  7:38                                   ` Dave Horsfall
@ 2020-05-14 12:25                                     ` ron
  0 siblings, 0 replies; 65+ messages in thread
From: ron @ 2020-05-14 12:25 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

> On Wed, 13 May 2020, Rich Morin wrote:
>
>> A Fortran implementation I used years ago kept constants in a "literal
>> pool".  So, if you called a subroutine, passing in a constant, there was
>> a possibility that the constant might be modified upon the routine's
>> return.  I don't recall this ever causing a problem in practice, but the
>> possibility was amusing...
>
> As I dimly recall, Fortran has always used call by value/result (or
> whatever the term is).  So, if you modify an argument that happened to be
> passed as a constant...
>
Fortran argument passing to functions is call by reference.  Some
compilers had a non-standard exception to allow call by value.




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

* Re: [TUHS] v7 K&R C
  2020-05-14  3:09                                   ` Charles Anthony
@ 2020-05-14 12:27                                     ` ron
  2020-05-14 12:27                                     ` ron
  2020-05-14 12:27                                     ` ron
  2 siblings, 0 replies; 65+ messages in thread
From: ron @ 2020-05-14 12:27 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society


> Ah yes.  A long time ago, some one came to me with a mysteriously behaving
> Pr1me FORTRAN program; after much head scratching, I found where they were
> changing the value of "0".
>

It was right up there when I traced a bug to find someone had added this
line to one of the headers:

#define notdef 1



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

* Re: [TUHS] v7 K&R C
  2020-05-14  3:09                                   ` Charles Anthony
  2020-05-14 12:27                                     ` ron
@ 2020-05-14 12:27                                     ` ron
  2020-05-14 12:27                                     ` ron
  2 siblings, 0 replies; 65+ messages in thread
From: ron @ 2020-05-14 12:27 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society


> Ah yes.  A long time ago, some one came to me with a mysteriously behaving
> Pr1me FORTRAN program; after much head scratching, I found where they were
> changing the value of "0".
>

It was right up there when I traced a bug to find someone had added this
line to one of the headers:

#define notdef 1



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

* Re: [TUHS] v7 K&R C
  2020-05-14  3:09                                   ` Charles Anthony
  2020-05-14 12:27                                     ` ron
  2020-05-14 12:27                                     ` ron
@ 2020-05-14 12:27                                     ` ron
  2 siblings, 0 replies; 65+ messages in thread
From: ron @ 2020-05-14 12:27 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society


> Ah yes.  A long time ago, some one came to me with a mysteriously behaving
> Pr1me FORTRAN program; after much head scratching, I found where they were
> changing the value of "0".
>

It was right up there when I traced a bug to find someone had added this
line to one of the headers:

#define notdef 1



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

* Re: [TUHS] v7 K&R C
  2020-05-14  2:44                                 ` Rich Morin
  2020-05-14  3:09                                   ` Charles Anthony
  2020-05-14  7:38                                   ` Dave Horsfall
@ 2020-05-14 17:13                                   ` Paul Winalski
  2 siblings, 0 replies; 65+ messages in thread
From: Paul Winalski @ 2020-05-14 17:13 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On 5/13/20, Rich Morin <rdm@cfcl.com> wrote:
>
> A Fortran implementation I used years ago kept constants in a "literal
> pool".  So, if you called a subroutine, passing in a constant, there was a
> possibility that the constant might be modified upon the routine's return.
> I don't recall this ever causing a problem in practice, but the possibility
> was amusing...

Any modern compiler worth its salt does literal pooling.  Fortunately
modern operating systems have the concept of read-only address space.
These days attempts to modify literal pool constants will give you a
memory access violation at the point where the illegal modification
was made.

-Paul W.

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

* Re: [TUHS] v7 K&R C
  2020-05-14  0:42                               ` John P. Linderman
  2020-05-14  2:44                                 ` Rich Morin
@ 2020-05-14 17:21                                 ` Larry McVoy
  2020-05-17 16:34                                   ` Derek Fawcus
  1 sibling, 1 reply; 65+ messages in thread
From: Larry McVoy @ 2020-05-14 17:21 UTC (permalink / raw)
  To: John P. Linderman; +Cc: The Eunuchs Hysterical Society

On Wed, May 13, 2020 at 08:42:55PM -0400, John P. Linderman wrote:
> I never liked call by reference. When I was trying to understand a chunk of
> code, it was a great mental simplification to know that whatever a called
> routine did, it couldn't have an effect on the code I was trying to
> understand except through a returned value and (ghastly) global variables.

Call by value is fine for things like a single integer or whatever.  When
you have some giant array, you want to pass a pointer.

And "const" helps a lot with indicating the subroutine isn't going to
change it.

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

* Re: [TUHS] v7 K&R C
  2020-05-13 23:36                             ` Dave Horsfall
  2020-05-14  0:42                               ` John P. Linderman
  2020-05-14  4:21                               ` Greg A. Woods
@ 2020-05-14 17:32                               ` Larry McVoy
  2020-05-14 22:32                                 ` Tony Finch
  2 siblings, 1 reply; 65+ messages in thread
From: Larry McVoy @ 2020-05-14 17:32 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

On Thu, May 14, 2020 at 09:36:57AM +1000, Dave Horsfall wrote:
> I had to learn C++ for a project at $WORK years ago (the client demanded
> it), and boy was I glad when I left...

Amen.  I'm being a whiney grumpy old man, but I'm sort of glad I'm at the
tail end of my career.  Going into it now, there are some bright spots,
and some dim ones, Go seems nice, Rust could have been nice but they just
had to come up with a different syntax, I can't see why anyone would do
anything other than an improved C like syntax, Java and C++ seem awful,
D tried but threw too much into the language like C++ did, if D had had
some restraint like Go does, D would probably be my language of choice.

Personally, I just want a modernized C.  If you want to see what I want
take a look at https://www.little-lang.org/

It's got some perl goodness, regexps are part of the syntax, switches
work on strings or regexps as well as constants, it's pleasant.  And 
completely doable as an extension to C.

Oh, and it has reference counting on auto allocated stuff so when it
goes out of scope, free() is automatic.  

--lm

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

* Re: [TUHS] v7 K&R C
  2020-05-14 17:32                               ` Larry McVoy
@ 2020-05-14 22:32                                 ` Tony Finch
  2020-05-16 23:53                                   ` Steffen Nurpmeso
  0 siblings, 1 reply; 65+ messages in thread
From: Tony Finch @ 2020-05-14 22:32 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

Larry McVoy <lm@mcvoy.com> wrote:
>
> It's got some perl goodness, regexps are part of the syntax, ....

I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
riff on lex being its Swiss Army Knife. I came to appreciate lex
regrettably late: lex makes it remarkably easy to chew through a huge pile
of text and feed the pieces to some library code written in C. I've been
using re2c recently (http://re2c.org/), which is differently weird than
lex, though it still uses YY in all its variable names. It's remarkable
how much newer lexer/parser generators can't escape from the user
interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Trafalgar: Cyclonic 6 to gale 8. Rough occasionally very rough in west and
south. Thundery showers. Good, occasionally poor.

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

* Re: [TUHS] v7 K&R C
  2020-05-14 22:32                                 ` Tony Finch
@ 2020-05-16 23:53                                   ` Steffen Nurpmeso
  2020-05-16 23:59                                     ` [TUHS] v7 K&R C [really lexers] Jon Steinhart
  2020-05-17  0:35                                     ` [TUHS] v7 K&R C Larry McVoy
  0 siblings, 2 replies; 65+ messages in thread
From: Steffen Nurpmeso @ 2020-05-16 23:53 UTC (permalink / raw)
  To: Tony Finch; +Cc: The Eunuchs Hysterical Society

Tony Finch wrote in
<alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
 |Larry McVoy <lm@mcvoy.com> wrote:
 |>
 |> It's got some perl goodness, regexps are part of the syntax, ....
 |
 |I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
 |Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
 |riff on lex being its Swiss Army Knife. I came to appreciate lex
 |regrettably late: lex makes it remarkably easy to chew through a huge pile
 |of text and feed the pieces to some library code written in C. I've been
 |using re2c recently (http://re2c.org/), which is differently weird than
 |lex, though it still uses YY in all its variable names. It's remarkable
 |how much newer lexer/parser generators can't escape from the user
 |interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/

P.S.: i really hate automated lexers.  I never ever got used to
use them.  For learning i once tried to use flex/bison, but
i failed really hard.  I like that blood, sweat and tears thing,
and using a lexer seems so shattered, all the pieces.  And i find
them really hard to read.

If you can deal with them they are surely a relief, especially in
rapidly moving syntax situations.  But if i look at settled source
code which uses it, for example usr.sbin/ospfd/parse.y, or
usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am
happy that i do not need to maintain that code.

--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] 65+ messages in thread

* Re: [TUHS] v7 K&R C [really lexers]
  2020-05-16 23:53                                   ` Steffen Nurpmeso
@ 2020-05-16 23:59                                     ` Jon Steinhart
  2020-05-17  0:04                                       ` Brantley Coile
  2020-05-17 16:31                                       ` Paul Winalski
  2020-05-17  0:35                                     ` [TUHS] v7 K&R C Larry McVoy
  1 sibling, 2 replies; 65+ messages in thread
From: Jon Steinhart @ 2020-05-16 23:59 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Steffen Nurpmeso writes:
> Tony Finch wrote in
> <alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
>  |Larry McVoy <lm@mcvoy.com> wrote:
>  |>
>  |> It's got some perl goodness, regexps are part of the syntax, ....
>  |
>  |I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
>  |Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
>  |riff on lex being its Swiss Army Knife. I came to appreciate lex
>  |regrettably late: lex makes it remarkably easy to chew through a huge pile
>  |of text and feed the pieces to some library code written in C. I've been
>  |using re2c recently (http://re2c.org/), which is differently weird than
>  |lex, though it still uses YY in all its variable names. It's remarkable
>  |how much newer lexer/parser generators can't escape from the user
>  |interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
>
> P.S.: i really hate automated lexers.  I never ever got used to
> use them.  For learning i once tried to use flex/bison, but
> i failed really hard.  I like that blood, sweat and tears thing,
> and using a lexer seems so shattered, all the pieces.  And i find
> them really hard to read.
>
> If you can deal with them they are surely a relief, especially in
> rapidly moving syntax situations.  But if i look at settled source
> code which uses it, for example usr.sbin/ospfd/parse.y, or
> usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am
> happy that i do not need to maintain that code.
>
> --steffen

Wow, I've had the opposite experience.  I find lex/yacc/flex/bison really
easy to use.  The issue, which I believe was covered in the early docs,
is that some languages are not designed with regularity in mind which makes
for ugly code.  But to be fair, that code is at least as ugly with hand-crafted
code.

I believe that the original wisecrack was directed towards FORTRAN.  My ancient
experience was that it was using lex/yacc for HSPICE was not going to work so I
had to hand-craft code for that.

Jon

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-05-16 23:59                                     ` [TUHS] v7 K&R C [really lexers] Jon Steinhart
@ 2020-05-17  0:04                                       ` Brantley Coile
  2020-05-17  1:23                                         ` Warner Losh
  2020-05-17 16:31                                       ` Paul Winalski
  1 sibling, 1 reply; 65+ messages in thread
From: Brantley Coile @ 2020-05-17  0:04 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

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

“The asteroid to kill this dinosaur is still in orbit.“

    —- Plan 9 lex man page

I always hand craft my lexers and use yacc to parse. Most  code on plan 9 does that as well.

  Brantley


On May 16, 2020, at 8:00 PM, Jon Steinhart <jon@fourwinds.com> wrote:

Steffen Nurpmeso writes:
Tony Finch wrote in
<alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
|Larry McVoy <lm@mcvoy.com> wrote:
|>
|> It's got some perl goodness, regexps are part of the syntax, ....
|
|I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
|Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
|riff on lex being its Swiss Army Knife. I came to appreciate lex
|regrettably late: lex makes it remarkably easy to chew through a huge pile
|of text and feed the pieces to some library code written in C. I've been
|using re2c recently (http://re2c.org/), which is differently weird than
|lex, though it still uses YY in all its variable names. It's remarkable
|how much newer lexer/parser generators can't escape from the user
|interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/

P.S.: i really hate automated lexers.  I never ever got used to
use them.  For learning i once tried to use flex/bison, but
i failed really hard.  I like that blood, sweat and tears thing,
and using a lexer seems so shattered, all the pieces.  And i find
them really hard to read.

If you can deal with them they are surely a relief, especially in
rapidly moving syntax situations.  But if i look at settled source
code which uses it, for example usr.sbin/ospfd/parse.y, or
usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am
happy that i do not need to maintain that code.

--steffen

Wow, I've had the opposite experience.  I find lex/yacc/flex/bison really
easy to use.  The issue, which I believe was covered in the early docs,
is that some languages are not designed with regularity in mind which makes
for ugly code.  But to be fair, that code is at least as ugly with hand-crafted
code.

I believe that the original wisecrack was directed towards FORTRAN.  My ancient
experience was that it was using lex/yacc for HSPICE was not going to work so I
had to hand-craft code for that.

Jon

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

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

* Re: [TUHS] v7 K&R C
  2020-05-16 23:53                                   ` Steffen Nurpmeso
  2020-05-16 23:59                                     ` [TUHS] v7 K&R C [really lexers] Jon Steinhart
@ 2020-05-17  0:35                                     ` Larry McVoy
  1 sibling, 0 replies; 65+ messages in thread
From: Larry McVoy @ 2020-05-17  0:35 UTC (permalink / raw)
  To: Tony Finch, Larry McVoy, The Eunuchs Hysterical Society

On Sun, May 17, 2020 at 01:53:08AM +0200, Steffen Nurpmeso wrote:
> Tony Finch wrote in
> <alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
>  |Larry McVoy <lm@mcvoy.com> wrote:
>  |>
>  |> It's got some perl goodness, regexps are part of the syntax, ....
>  |
>  |I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
>  |Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
>  |riff on lex being its Swiss Army Knife. I came to appreciate lex
>  |regrettably late: lex makes it remarkably easy to chew through a huge pile
>  |of text and feed the pieces to some library code written in C. I've been
>  |using re2c recently (http://re2c.org/), which is differently weird than
>  |lex, though it still uses YY in all its variable names. It's remarkable
>  |how much newer lexer/parser generators can't escape from the user
>  |interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
> 
> P.S.: i really hate automated lexers.  I never ever got used to
> use them.  For learning i once tried to use flex/bison, but
> i failed really hard.  I like that blood, sweat and tears thing,
> and using a lexer seems so shattered, all the pieces.  And i find
> them really hard to read.

They are not bad if you are good at it.  One of my guys has a PhD in
compilers and he's good at it.

They are not good at performance.  BitKeeper has an extensive printf
like (sort of, different syntax) language that can be used to customize
log output.  Rob originally did all that in flex/bison but the performance
started to hurt so he rewrote it all:

/*
 * This is a recursive-descent parser that implements the following
 * grammar for dspecs (where [[...]] indicates an optional clause
 * and {{...}} indicates 0 or more repetitions of):
 *
 * <stmt_list> -> {{ <stmt> }}
 * <stmt>      -> $if(<expr>){<stmt_list>}[[$else{<stmt_list>}]]
 *             -> $unless(<expr>){<stmt_list>}[[$else{<stmt_list>}]]
 *             -> $each(:ID:){<stmt_list>}
 *             -> ${<num>=<stmt_list>}
 *             -> <atom>
 * <expr>      -> <expr2> {{ <logop> <expr2> }}
 * <expr2>     -> <str> <relop> <str>
 *             -> <str>
 *             -> (<expr>)
 *             -> !<expr2>
 * <str>       -> {{ <atom> }}
 * <atom>      -> char
 *             -> escaped_char
 *             -> :ID:
 *             -> (:ID:)
 *             -> $<num>
 * <logop>     -> " && " | " || "
 * <relop>     -> "=" | "!=" | "=~"
 *             -> " -eq " | " -ne " | " -gt " | " -ge " | " -lt " | " -le "
 *
 * This grammar is ambiguous due to (:ID:) loooking like a
 * parenthesized sub-expression.  The code tries to parse (:ID:) first
 * as an $each variable, then as a regular :ID:, then as regular text.
 *
 * Note that this is broken: $if((:MERGE:)){:REV:}
 *
 * The following procedures can be thought of as implementing an
 * attribute grammar where the output parameters are synthesized
 * attributes which hold the expression values and the next token
 * of lookahead in some cases.  It has been written for speed.
 *
 * NOTE: out==0 means evaluate but throw away.
 *
 * Written by Rob Netzer <rob@bolabs.com> with some hacking
 * by wscott & lm.
 */

That stuff screams perf wise.



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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-05-17  0:04                                       ` Brantley Coile
@ 2020-05-17  1:23                                         ` Warner Losh
  2020-05-17  1:36                                           ` Brantley Coile
  2020-06-13 21:24                                           ` scj
  0 siblings, 2 replies; 65+ messages in thread
From: Warner Losh @ 2020-05-17  1:23 UTC (permalink / raw)
  To: Brantley Coile; +Cc: The Eunuchs Hysterical Society

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

On Sat, May 16, 2020, 6:05 PM Brantley Coile <brantley@coraid.com> wrote:

> “The asteroid to kill this dinosaur is still in orbit.“
>
>     —- Plan 9 lex man page
>
>
> I always hand craft my lexers and use yacc to parse. Most  code on plan 9
> does that as well.
>

Wow! That is the most awesome thing I've seen in a while....

Warner


  Brantley
>
>
> On May 16, 2020, at 8:00 PM, Jon Steinhart <jon@fourwinds.com> wrote:
>
> Steffen Nurpmeso writes:
>
> Tony Finch wrote in
>
> <alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
>
> |Larry McVoy <lm@mcvoy.com> wrote:
>
> |>
>
> |> It's got some perl goodness, regexps are part of the syntax, ....
>
> |
>
> |I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
>
> |Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
>
> |riff on lex being its Swiss Army Knife. I came to appreciate lex
>
> |regrettably late: lex makes it remarkably easy to chew through a huge pile
>
> |of text and feed the pieces to some library code written in C. I've been
>
> |using re2c recently (http://re2c.org/), which is differently weird than
>
> |lex, though it still uses YY in all its variable names. It's remarkable
>
> |how much newer lexer/parser generators can't escape from the user
>
> |interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
>
>
> P.S.: i really hate automated lexers.  I never ever got used to
>
> use them.  For learning i once tried to use flex/bison, but
>
> i failed really hard.  I like that blood, sweat and tears thing,
>
> and using a lexer seems so shattered, all the pieces.  And i find
>
> them really hard to read.
>
>
> If you can deal with them they are surely a relief, especially in
>
> rapidly moving syntax situations.  But if i look at settled source
>
> code which uses it, for example usr.sbin/ospfd/parse.y, or
>
> usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am
>
> happy that i do not need to maintain that code.
>
>
> --steffen
>
>
> Wow, I've had the opposite experience.  I find lex/yacc/flex/bison really
> easy to use.  The issue, which I believe was covered in the early docs,
> is that some languages are not designed with regularity in mind which makes
> for ugly code.  But to be fair, that code is at least as ugly with
> hand-crafted
> code.
>
> I believe that the original wisecrack was directed towards FORTRAN.  My
> ancient
> experience was that it was using lex/yacc for HSPICE was not going to work
> so I
> had to hand-craft code for that.
>
> Jon
>
>

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

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-05-17  1:23                                         ` Warner Losh
@ 2020-05-17  1:36                                           ` Brantley Coile
  2020-06-13 21:24                                           ` scj
  1 sibling, 0 replies; 65+ messages in thread
From: Brantley Coile @ 2020-05-17  1:36 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

It looks like only grap and pic have mkfiles that invoke lex.


> On May 16, 2020, at 9:23 PM, Warner Losh <imp@bsdimp.com> wrote:
> 
> 
> 
> On Sat, May 16, 2020, 6:05 PM Brantley Coile <brantley@coraid.com> wrote:
> “The asteroid to kill this dinosaur is still in orbit.“
>     —- Plan 9 lex man page
> 
> I always hand craft my lexers and use yacc to parse. Most  code on plan 9 does that as well. 
> 
> Wow! That is the most awesome thing I've seen in a while....
> 
> Warner
> 
> 
>   Brantley
> 
> 
>> On May 16, 2020, at 8:00 PM, Jon Steinhart <jon@fourwinds.com> wrote:
>> 
>> Steffen Nurpmeso writes:
>>> Tony Finch wrote in
>>> <alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>:
>>> |Larry McVoy <lm@mcvoy.com> wrote:
>>> |>
>>> |> It's got some perl goodness, regexps are part of the syntax, ....
>>> |
>>> |I got into Unix after perl and I've used it a lot. Back in the 1990s I saw
>>> |Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a
>>> |riff on lex being its Swiss Army Knife. I came to appreciate lex
>>> |regrettably late: lex makes it remarkably easy to chew through a huge pile
>>> |of text and feed the pieces to some library code written in C. I've been
>>> |using re2c recently (http://re2c.org/), which is differently weird than
>>> |lex, though it still uses YY in all its variable names. It's remarkable
>>> |how much newer lexer/parser generators can't escape from the user
>>> |interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/
>>> 
>>> P.S.: i really hate automated lexers.  I never ever got used to
>>> use them.  For learning i once tried to use flex/bison, but
>>> i failed really hard.  I like that blood, sweat and tears thing,
>>> and using a lexer seems so shattered, all the pieces.  And i find
>>> them really hard to read.
>>> 
>>> If you can deal with them they are surely a relief, especially in
>>> rapidly moving syntax situations.  But if i look at settled source
>>> code which uses it, for example usr.sbin/ospfd/parse.y, or
>>> usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am
>>> happy that i do not need to maintain that code.
>>> 
>>> --steffen
>> 
>> Wow, I've had the opposite experience.  I find lex/yacc/flex/bison really
>> easy to use.  The issue, which I believe was covered in the early docs,
>> is that some languages are not designed with regularity in mind which makes
>> for ugly code.  But to be fair, that code is at least as ugly with hand-crafted
>> code.
>> 
>> I believe that the original wisecrack was directed towards FORTRAN.  My ancient
>> experience was that it was using lex/yacc for HSPICE was not going to work so I
>> had to hand-craft code for that.
>> 
>> Jon


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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-05-16 23:59                                     ` [TUHS] v7 K&R C [really lexers] Jon Steinhart
  2020-05-17  0:04                                       ` Brantley Coile
@ 2020-05-17 16:31                                       ` Paul Winalski
  1 sibling, 0 replies; 65+ messages in thread
From: Paul Winalski @ 2020-05-17 16:31 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Regarding lex/yacc/flex/bison, I remember (ca. 1980) when DEC's
compiler group first got their hands on lex and yacc.  For yucks they
put the BLISS grammar through yacc.  It came back with an error
message that the grammar was ambiguous.  And it turned out that, yes,
Wulf's grammar for BLISS had an obscure corner case that *was*
ambiguous.  That caused quite a stir.

-Paul W.

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

* Re: [TUHS] v7 K&R C
  2020-05-14 17:21                                 ` Larry McVoy
@ 2020-05-17 16:34                                   ` Derek Fawcus
  0 siblings, 0 replies; 65+ messages in thread
From: Derek Fawcus @ 2020-05-17 16:34 UTC (permalink / raw)
  To: tuhs

On Thu, May 14, 2020 at 10:21:07AM -0700, Larry McVoy wrote:
> On Wed, May 13, 2020 at 08:42:55PM -0400, John P. Linderman wrote:
> > I never liked call by reference. When I was trying to understand a chunk of
> > code, it was a great mental simplification to know that whatever a called
> > routine did, it couldn't have an effect on the code I was trying to
> > understand except through a returned value and (ghastly) global variables.

That has always been my issue with the C++ references, that one could not
read a piece of code in isolation, and know when a reference may be made.

I guess I'd be happy with references if the syntax always required one to
write '&x' when they're being created, then the called function can choose
if it either wishes to use a pointer or a reference, the only difference
being the syntax used to deref the reference.

As to Doug's point about new arithmetic types and overloading, I recall
a few years ago reading on the 9fans list about an extension there (in KenC?)
which supported them in C.  I've not managed to dig up the details again,
maybe someone else could.  As I recall it involved defining structs.

> Call by value is fine for things like a single integer or whatever.  When
> you have some giant array, you want to pass a pointer.
> 
> And "const" helps a lot with indicating the subroutine isn't going to
> change it.

However that is simply the ABI, i.e. it should be possible for a sufficiently
clever compiler to implement such a call-by-value as a call-by-constish-reference.

i.e. this:
    somefn(struct s p) {...}
    struct s ss;  somefn(ss);

in effect becomes syntax sugar for:
    somefn(constish ref struct s p) {...}
    struct s ss;  somefn(&ss);

Where 'constish' does not allow 'ss' to be altered even if somefn() assigns
to 'p', because in that case it would do sufficient copying so as to
make things work.  There was a proposed MIPS ABI which stated this.

The current C semantics in effect do that, but with the ABIs always having
the caller make a copy and pass a reference to it, rather than allowing the
callee to make a copy if/when required.

DF

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-05-17  1:23                                         ` Warner Losh
  2020-05-17  1:36                                           ` Brantley Coile
@ 2020-06-13 21:24                                           ` scj
  2020-06-14  8:47                                             ` arnold
  2020-06-14 12:52                                             ` Richard Salz
  1 sibling, 2 replies; 65+ messages in thread
From: scj @ 2020-06-13 21:24 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

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

I also gave up on lex for parsing fairly early.   The problem was
reserved words.  These looked like identifiers, but the state machine to
pick out a couple of dozen reserved words out of all identifiers was too
big for the PDP-11.   When I wrote spell, I ran into the same problem. 
I had some rules that wanted to convert plurals to singular forms that
would be found in the dictionary.   Writing a rule to recognize .*ies
and convert the "ies" to "y" blew out the memory after only a handful of
patterns.   My solution was to pick up words and reverse them before
passing them through lex, so I looked for the pattern "sei.*", converted
it to "y" and then reversed the word again.  As it turned out, I only
owned spell for a few weeks because Doug and others grabbed it and ran
with it... 

Steve

---

On 2020-05-16 18:23, Warner Losh wrote:

> On Sat, May 16, 2020, 6:05 PM Brantley Coile <brantley@coraid.com> wrote: 
> 
>> "The asteroid to kill this dinosaur is still in orbit."
>> 
>> --- Plan 9 lex man page
>> 
>> I always hand craft my lexers and use yacc to parse. Most  code on plan 9 does that as well.
> 
> Wow! That is the most awesome thing I've seen in a while.... 
> 
> Warner 
> 
> Brantley 
> 
> On May 16, 2020, at 8:00 PM, Jon Steinhart <jon@fourwinds.com> wrote:
> 
> Steffen Nurpmeso writes:
> Tony Finch wrote in <alpine.DEB.2.20.2005142316170.3374@grey.csi.cam.ac.uk>: |Larry McVoy <lm@mcvoy.com> wrote: |> |> It's got some perl goodness, regexps are part of the syntax, .... | |I got into Unix after perl and I've used it a lot. Back in the 1990s I saw |Henry Spencer's joke that perl was the Swiss Army Chainsaw of Unix, as a |riff on lex being its Swiss Army Knife. I came to appreciate lex |regrettably late: lex makes it remarkably easy to chew through a huge pile |of text and feed the pieces to some library code written in C. I've been |using re2c recently (http://re2c.org/), which is differently weird than |lex, though it still uses YY in all its variable names. It's remarkable |how much newer lexer/parser generators can't escape from the user |interface of lex/yacc. Another YY example: http://www.hwaci.com/sw/lemon/ P.S.: i really hate automated lexers.  I never ever got used to use them.  For learning i once tried to use flex/bison, but i failed really hard.  I like
that blood, sweat and tears thing, and using a lexer seems so shattered, all the pieces.  And i find them really hard to read. If you can deal with them they are surely a relief, especially in rapidly moving syntax situations.  But if i look at settled source code which uses it, for example usr.sbin/ospfd/parse.y, or usr.sbin/smtpd/parse.y, both of OpenBSD, then i feel lost and am happy that i do not need to maintain that code. --steffen 
> Wow, I've had the opposite experience.  I find lex/yacc/flex/bison really
> easy to use.  The issue, which I believe was covered in the early docs,
> is that some languages are not designed with regularity in mind which makes
> for ugly code.  But to be fair, that code is at least as ugly with hand-crafted
> code.
> 
> I believe that the original wisecrack was directed towards FORTRAN.  My ancient
> experience was that it was using lex/yacc for HSPICE was not going to work so I
> had to hand-craft code for that.
> 
> Jon

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

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-06-13 21:24                                           ` scj
@ 2020-06-14  8:47                                             ` arnold
  2020-06-14 12:52                                             ` Richard Salz
  1 sibling, 0 replies; 65+ messages in thread
From: arnold @ 2020-06-14  8:47 UTC (permalink / raw)
  To: scj, imp; +Cc: tuhs

scj@yaccman.com wrote:

> As it turned out, I only owned spell for a few weeks because Doug and
> others grabbed it and ran with it...
>
> Steve

Who else besides Doug worked on spell?

Do I understand correctly that you invented the original pipeline based
spell:

	tr ... |				# split words to one line
		tr ... | 			# lower case
			sort -u |		# sort and uniq
				comm -12 - dict	# find words not in dictionary

I didn't know that you'd worked on a rewrite in C.

Thanks,

Arnold

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-06-13 21:24                                           ` scj
  2020-06-14  8:47                                             ` arnold
@ 2020-06-14 12:52                                             ` Richard Salz
  2020-06-14 14:03                                               ` Ralph Corderoy
  1 sibling, 1 reply; 65+ messages in thread
From: Richard Salz @ 2020-06-14 12:52 UTC (permalink / raw)
  To: scj; +Cc: The Eunuchs Hysterical Society

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

Does anyone have the Usenix paper (80's timeframe I think) about making lex
go fast?  It was by Vern Paxson or Van Jacobson IIRC. Maybe only an
abstract was published.  The talk ended with a chart showing some CPU
times, and the modified lex was only slightly slower than cat. Maybe Vern
since he contributed to what became flex.

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

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-06-14 12:52                                             ` Richard Salz
@ 2020-06-14 14:03                                               ` Ralph Corderoy
  2020-06-14 14:26                                                 ` arnold
  0 siblings, 1 reply; 65+ messages in thread
From: Ralph Corderoy @ 2020-06-14 14:03 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Eunuchs Hysterical Society

Hi Rich,

> Does anyone have the Usenix paper (80's timeframe I think) about making lex
> go fast?  It was by Vern Paxson or Van Jacobson IIRC. Maybe only an
> abstract was published.  The talk ended with a chart showing some CPU
> times, and the modified lex was only slightly slower than cat. Maybe Vern
> since he contributed to what became flex.

Google Scholar's ‘Vancouver’ style citation:

    Jacobson V. Tuning UNIX Lex or it's NOT true what they say
    about Lex.  InUSENIX Conference Proceedings (Washington,
    DC, Winter 1987) 1987 (pp. 163-164).

Lack of space after ‘In’ is Google, not me.

I didn't find the paper itself, just citations of it.

-- 
Cheers, Ralph.

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-06-14 14:03                                               ` Ralph Corderoy
@ 2020-06-14 14:26                                                 ` arnold
  2020-06-14 14:48                                                   ` Ralph Corderoy
  0 siblings, 1 reply; 65+ messages in thread
From: arnold @ 2020-06-14 14:26 UTC (permalink / raw)
  To: rich.salz, ralph; +Cc: tuhs

Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Hi Rich,
>
> > Does anyone have the Usenix paper (80's timeframe I think) about making lex
> > go fast?  It was by Vern Paxson or Van Jacobson IIRC. Maybe only an
> > abstract was published.  The talk ended with a chart showing some CPU
> > times, and the modified lex was only slightly slower than cat. Maybe Vern
> > since he contributed to what became flex.
>
> Google Scholar's ‘Vancouver’ style citation:
>
>     Jacobson V. Tuning UNIX Lex or it's NOT true what they say
>     about Lex.  InUSENIX Conference Proceedings (Washington,
>     DC, Winter 1987) 1987 (pp. 163-164).
>
> Lack of space after ‘In’ is Google, not me.
>
> I didn't find the paper itself, just citations of it.

I'm pretty sure I have those proceedings. Given that it's 2 pages,
it's probably just an abstract. If there's interest, I can try to scan
the pages.

Arnold

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-06-14 14:26                                                 ` arnold
@ 2020-06-14 14:48                                                   ` Ralph Corderoy
  2020-06-15  1:12                                                     ` Warren Toomey
  0 siblings, 1 reply; 65+ messages in thread
From: Ralph Corderoy @ 2020-06-14 14:48 UTC (permalink / raw)
  To: arnold; +Cc: tuhs

Hi Arnold,

> I'm pretty sure I have those proceedings. Given that it's 2 pages,
> it's probably just an abstract.

Yes, it's just the abstract, says
https://compilers.iecc.com/comparch/article/87-05-012

-- 
Cheers, Ralph.

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-06-14 14:48                                                   ` Ralph Corderoy
@ 2020-06-15  1:12                                                     ` Warren Toomey
  2020-06-15  1:29                                                       ` Warren Toomey
  0 siblings, 1 reply; 65+ messages in thread
From: Warren Toomey @ 2020-06-15  1:12 UTC (permalink / raw)
  To: tuhs

On Sun, Jun 14, 2020 at 03:48:19PM +0100, Ralph Corderoy wrote:
> Hi Arnold,
> 
> > I'm pretty sure I have those proceedings. Given that it's 2 pages,
> > it's probably just an abstract.
> 
> Yes, it's just the abstract, says
> https://compilers.iecc.com/comparch/article/87-05-012

Clem was kind enough to send the scan to me, and it's now here:
https://www.tuhs.org/Archive/Documentation/Papers/TuningUnixLex_Jacobson_USENIX_Winter_1987_pp163_164.pdf

Cheers, Warren

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-06-15  1:12                                                     ` Warren Toomey
@ 2020-06-15  1:29                                                       ` Warren Toomey
  2020-06-15  6:06                                                         ` arnold
  0 siblings, 1 reply; 65+ messages in thread
From: Warren Toomey @ 2020-06-15  1:29 UTC (permalink / raw)
  To: tuhs

On Mon, Jun 15, 2020 at 11:12:30AM +1000, Warren Toomey wrote:
> Clem was kind enough to send the scan to me, and it's now here:
> https://www.tuhs.org/Archive/Documentation/Papers/TuningUnixLex_Jacobson_USENIX_Winter_1987_pp163_164.pdf

John R. Levine might be a person to ask to see if he has a copy of
the paper.
	Warren

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

* Re: [TUHS] v7 K&R C [really lexers]
  2020-06-15  1:29                                                       ` Warren Toomey
@ 2020-06-15  6:06                                                         ` arnold
  0 siblings, 0 replies; 65+ messages in thread
From: arnold @ 2020-06-15  6:06 UTC (permalink / raw)
  To: wkt, tuhs

Warren Toomey <wkt@tuhs.org> wrote:

> On Mon, Jun 15, 2020 at 11:12:30AM +1000, Warren Toomey wrote:
> > Clem was kind enough to send the scan to me, and it's now here:
> > https://www.tuhs.org/Archive/Documentation/Papers/TuningUnixLex_Jacobson_USENIX_Winter_1987_pp163_164.pdf
>
> John R. Levine might be a person to ask to see if he has a copy of
> the paper.
> 	Warren

I've just done so, by posting to comp.compilers.

Arnold

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

* Re: [TUHS] v7 K&R C [really lexers]
@ 2020-06-14 13:55 Doug McIlroy
  0 siblings, 0 replies; 65+ messages in thread
From: Doug McIlroy @ 2020-06-14 13:55 UTC (permalink / raw)
  To: tuhs

Interesting. My "speak" program had a trivial lexer that
recognized literal tokens, many of which were prefixes
of others, by maximum-munch binary search in a list of
1600 entries. Entries gave token+translation+rewrite.
The whole thing fit in 15K.

Many years later I wrote a regex recognizer that special-cased
alternations of lots of literals. I believe Gnu's regex.c does
that, too. (My regex also supported conjunction and negation--
legitimate regular-language operations--implemented by
continuation-passing to avoid huge finite-state machines.)

We have here a case of imperfect communication in 1127. Had I
been conscious of the lex-explosion problem, I might have
thought of speak and put support for speak-like tables
into lex. As it happened, I only used yacc/lex once, quite
successfully, for a small domain-specific language. 

Doug

Steve Johnson wrote:

I also gave up on lex for parsing fairly early.   The problem was
reserved words.  These looked like identifiers, but the state machine to
pick out a couple of dozen reserved words out of all identifiers was too
big for the PDP-11.   When I wrote spell, I ran into the same problem.
I had some rules that wanted to convert plurals to singular forms that
would be found in the dictionary.   Writing a rule to recognize .*ies
and convert the "ies" to "y" blew out the memory after only a handful of
patterns.   My solution was to pick up words and reverse them before
passing them through lex, so I looked for the pattern "sei.*", converted
it to "y" and then reversed the word again.  As it turned out, I only
owned spell for a few weeks because Doug and others grabbed it and ran
with it.

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

* Re: [TUHS] v7 K&R C [really lexers]
@ 2020-05-17  2:07 Nelson H. F. Beebe
  0 siblings, 0 replies; 65+ messages in thread
From: Nelson H. F. Beebe @ 2020-05-17  2:07 UTC (permalink / raw)
  To: tuhs

Brantley Coile <brantley@coraid.com> wrote on Sun, 17 May 2020 01:36:16 +0000:

>> It looks like only grap and pic have mkfiles that invoke lex.

Both of those are Brian Kernighan's work, and from the FIXES file
in his nawk, I can offer this quote:

>> ...
>> Aug 9, 1997:
>> 	somewhat regretfully, replaced the ancient lex-based lexical
>> 	analyzer with one written in C.  it's longer, generates less code,
>> 	and more portable; the old one depended too much on mysterious
>> 	properties of lex that were not preserved in other environments.
>> 	in theory these recognize the same language.
>> ...

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

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

end of thread, other threads:[~2020-06-15  6:07 UTC | newest]

Thread overview: 65+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-25  1:59 [TUHS] v7 K&R C Adam Thornton
2020-04-25  2:37 ` Charles Anthony
2020-04-25  2:47   ` Adam Thornton
2020-04-25  2:51     ` Rob Pike
2020-04-25  2:54       ` Rob Pike
2020-04-25  3:04         ` Larry McVoy
2020-04-25  3:30           ` Clem Cole
2020-04-25  3:43             ` Larry McVoy
2020-04-25  3:54               ` Jon Steinhart
2020-04-25 11:44                 ` Michael Kjörling
2020-04-25 13:17             ` Dan Cross
2020-05-11  0:28         ` scj
2020-05-11  0:32           ` Rob Pike
2020-05-11  0:57             ` Larry McVoy
2020-05-11 17:32               ` Greg A. Woods
2020-05-11 18:25                 ` Paul Winalski
2020-05-11 18:37                   ` Clem Cole
2020-05-11 19:12                     ` Paul Winalski
2020-05-11 19:57                       ` joe mcguckin
2020-05-11 20:25                         ` Larry McVoy
2020-05-12 17:23                           ` Paul Winalski
2020-05-12 17:35                             ` ron
2020-05-12 17:42                               ` Larry McVoy
2020-05-12 18:36                               ` Paul Winalski
2020-05-13 23:36                             ` Dave Horsfall
2020-05-14  0:42                               ` John P. Linderman
2020-05-14  2:44                                 ` Rich Morin
2020-05-14  3:09                                   ` Charles Anthony
2020-05-14 12:27                                     ` ron
2020-05-14 12:27                                     ` ron
2020-05-14 12:27                                     ` ron
2020-05-14  7:38                                   ` Dave Horsfall
2020-05-14 12:25                                     ` ron
2020-05-14 17:13                                   ` Paul Winalski
2020-05-14 17:21                                 ` Larry McVoy
2020-05-17 16:34                                   ` Derek Fawcus
2020-05-14  4:21                               ` Greg A. Woods
2020-05-14  4:40                                 ` Warner Losh
2020-05-14 17:32                               ` Larry McVoy
2020-05-14 22:32                                 ` Tony Finch
2020-05-16 23:53                                   ` Steffen Nurpmeso
2020-05-16 23:59                                     ` [TUHS] v7 K&R C [really lexers] Jon Steinhart
2020-05-17  0:04                                       ` Brantley Coile
2020-05-17  1:23                                         ` Warner Losh
2020-05-17  1:36                                           ` Brantley Coile
2020-06-13 21:24                                           ` scj
2020-06-14  8:47                                             ` arnold
2020-06-14 12:52                                             ` Richard Salz
2020-06-14 14:03                                               ` Ralph Corderoy
2020-06-14 14:26                                                 ` arnold
2020-06-14 14:48                                                   ` Ralph Corderoy
2020-06-15  1:12                                                     ` Warren Toomey
2020-06-15  1:29                                                       ` Warren Toomey
2020-06-15  6:06                                                         ` arnold
2020-05-17 16:31                                       ` Paul Winalski
2020-05-17  0:35                                     ` [TUHS] v7 K&R C Larry McVoy
2020-05-11 18:37                   ` Larry McVoy
2020-05-11  2:08           ` Lawrence Stewart
2020-05-11 11:36           ` Michael Kjörling
2020-04-25  3:37       ` Dave Horsfall
2020-04-27 13:19       ` Tony Finch
2020-04-25  2:50   ` Adam Thornton
2020-04-25  5:59     ` Lars Brinkhoff
2020-05-17  2:07 [TUHS] v7 K&R C [really lexers] Nelson H. F. Beebe
2020-06-14 13:55 Doug McIlroy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).