25 Apr
2020
25 Apr
'20
1:59 a.m.
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
2:47 a.m.
On Apr 24, 2020, at 7:37 PM, Charles Anthony
<charles.unix.pro(a)gmail.com> wrote:
On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)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
2:50 a.m.
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
2:51 a.m.
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(a)gmail.com> wrote:
On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro(a)gmail.com>
wrote:
On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)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
2:54 a.m.
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(a)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(a)gmail.com>
wrote:
>
>
> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro(a)gmail.com>
> wrote:
>
>
>
> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)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
>
>
3:04 a.m.
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(a)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(a)gmail.com>
> wrote:
>
>>
>>
>> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro(a)gmail.com>
>> wrote:
>>
>>
>>
>> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)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
3:30 a.m.
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(a)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:
--
Sent from a handheld expect more typos than usual
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(a)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(a)gmail.com>
> wrote:
>
>>
>>
>> On Apr 24, 2020, at 7:37 PM, Charles Anthony <
charles.unix.pro(a)gmail.com>
>> wrote:
>>
>>
>>
>> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)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
3:37 a.m.
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
3:43 a.m.
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(a)mcvoy.com> wrote:
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
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:
--
Sent from a handheld expect more typos than usual 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(a)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(a)gmail.com>
> wrote:
>
>>
>>
>> On Apr 24, 2020, at 7:37 PM, Charles Anthony <
charles.unix.pro(a)gmail.com>
>> wrote:
>>
>>
>>
>> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)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
3:54 a.m.
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
};
11:44 a.m.
On 24 Apr 2020 20:54 -0700, from jon(a)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(a)darkstar.fourwinds.com> from 13 Nov 2019
10:02 -0800 / 18:02 UTC.
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
1:17 p.m.
On Fri, Apr 24, 2020 at 11:31 PM Clem Cole <clemc(a)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(a)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:
--
Sent from a handheld expect more typos than usual
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(a)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(a)gmail.com>
> wrote:
>
>>
>>
>> On Apr 24, 2020, at 7:37 PM, Charles Anthony <
charles.unix.pro(a)gmail.com>
>> wrote:
>>
>>
>>
>> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)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
27 Apr
27 Apr
1:19 p.m.
Rob Pike <robpike(a)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(a)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.
11 May
11 May
12:28 a.m.
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(a)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(a)gmail.com> wrote:
On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro(a)gmail.com> wrote:
On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)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
12:32 a.m.
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(a)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(a)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(a)gmail.com>
wrote:
On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro(a)gmail.com>
wrote:
On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)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
12:57 a.m.
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(a)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
2:08 a.m.
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_…
<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(a)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(a)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(a)gmail.com
<mailto:athornton@gmail.com>> wrote:
>
>
>> On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro(a)gmail.com
<mailto:charles.unix.pro@gmail.com>> wrote:
>>
>>
>>
>> On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)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
11:36 a.m.
On 10 May 2020 17:28 -0700, from scj(a)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(a)kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
5:32 p.m.
At Sun, 10 May 2020 17:57:46 -0700, Larry McVoy <lm(a)mcvoy.com> wrote:
Subject: Re: [TUHS] v7 K&R C
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.
On Mon, May 11, 2020 at 10:28 AM
<scj(a)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.
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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
6:25 p.m.
On 5/11/20, Greg A. Woods <woods(a)robohack.ca> wrote:
Indeed.
-Paul W.
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.
6:37 p.m.
On Mon, May 11, 2020 at 2:25 PM Paul Winalski <paul.winalski(a)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>
6:37 p.m.
On Mon, May 11, 2020 at 02:25:15PM -0400, Paul Winalski wrote:
On 5/11/20, Greg A. Woods <woods(a)robohack.ca>
wrote:
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.
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".
Indeed.
-Paul W.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
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.
7:12 p.m.
On 5/11/20, Clem Cole <clemc(a)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.
7:57 p.m.
Maybe it’s time for C++ subset ‘G'
Joe McGuckin
ViaNet Communications
joe(a)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(a)gmail.com> wrote:
On 5/11/20, Clem Cole <clemc(a)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.
8:25 p.m.
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(a)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(a)gmail.com> wrote:
>
> On 5/11/20, Clem Cole <clemc(a)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
12 May
12 May
5:23 p.m.
On 5/11/20, Larry McVoy <lm(a)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.
5:35 p.m.
On 5/11/20, Larry McVoy <lm(a)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.
5:42 p.m.
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(a)ronnatalie.com wrote:
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
On 5/11/20,
Larry McVoy <lm(a)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.
6:36 p.m.
On 5/12/20, ron(a)ronnatalie.com <ron(a)ronnatalie.com> wrote:
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.
On 5/11/20,
Larry McVoy <lm(a)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.
13 May
13 May
11:36 p.m.
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
14 May
14 May
12:42 a.m.
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(a)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
2:44 a.m.
On May 13, 2020, at 17:42, John P. Linderman
<jpl.jpl(a)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
3:09 a.m.
On Wed, May 13, 2020 at 7:45 PM Rich Morin <rdm(a)cfcl.com> wrote:
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
On May 13,
2020, at 17:42, John P. Linderman <jpl.jpl(a)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...
--
X-Clacks-Overhead: GNU Terry Pratchett
4:21 a.m.
At Thu, 14 May 2020 09:36:57 +1000 (EST), Dave Horsfall <dave(a)horsfall.org> wrote:
Subject: Re: [TUHS] v7 K&R C
On Tue, 12 May 2020, Paul Winalski wrote:
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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
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. 
4:40 a.m.
On Wed, May 13, 2020, 10:22 PM Greg A. Woods <woods(a)robohack.ca> wrote:
At Thu, 14 May 2020 09:36:57 +1000 (EST), Dave
Horsfall <dave(a)horsfall.org>
wrote:
Subject: Re: [TUHS] v7 K&R C
Queue rant about << and >> overloading...
Warner
--
On Tue, 12 May 2020, Paul Winalski wrote:
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.
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. Greg A. Woods
<gwoods(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
7:38 a.m.
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
12:25 p.m.
On Wed, 13 May 2020, Rich Morin wrote:
Fortran argument passing to functions is call by reference. Some
compilers had a non-standard exception to allow call by value.
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...
12:27 p.m.
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
12:27 p.m.
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
12:27 p.m.
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
5:13 p.m.
On 5/13/20, Rich Morin <rdm(a)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.
5:21 p.m.
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.
5:32 p.m.
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
10:32 p.m.
Larry McVoy <lm(a)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(a)dotat.at> http://dotat.at/
Trafalgar: Cyclonic 6 to gale 8. Rough occasionally very rough in west and
south. Thundery showers. Good, occasionally poor.
16 May
16 May
11:53 p.m.
Tony Finch wrote in
<alpine.DEB.2.20.2005142316170.3374(a)grey.csi.cam.ac.uk>uk>:
|Larry McVoy <lm(a)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)
11:59 p.m.
New subject: v7 K&R C [really lexers]
Steffen Nurpmeso writes:
Tony Finch wrote in
<alpine.DEB.2.20.2005142316170.3374(a)grey.csi.cam.ac.uk>uk>:
|Larry McVoy <lm(a)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
17 May
17 May
12:04 a.m.
New subject: v7 K&R C [really lexers]
“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(a)fourwinds.com> wrote:
Steffen Nurpmeso writes:
Tony Finch wrote in
<alpine.DEB.2.20.2005142316170.3374(a)grey.csi.cam.ac.uk>uk>:
|Larry McVoy <lm(a)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
12:35 a.m.
On Sun, May 17, 2020 at 01:53:08AM +0200, Steffen Nurpmeso wrote:
Tony Finch wrote in
<alpine.DEB.2.20.2005142316170.3374(a)grey.csi.cam.ac.uk>uk>:
|Larry McVoy <lm(a)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(a)bolabs.com> with some hacking
* by wscott & lm.
*/
That stuff screams perf wise.
1:23 a.m.
New subject: v7 K&R C [really lexers]
On Sat, May 16, 2020, 6:05 PM Brantley Coile <brantley(a)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(a)fourwinds.com> wrote:
Steffen Nurpmeso writes:
Tony Finch wrote in
<alpine.DEB.2.20.2005142316170.3374(a)grey.csi.cam.ac.uk>uk>:
|Larry McVoy <lm(a)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
1:36 a.m.
New subject: v7 K&R C [really lexers]
It looks like only grap and pic have mkfiles that invoke lex.
On May 16, 2020, at 9:23 PM, Warner Losh
<imp(a)bsdimp.com> wrote:
On Sat, May 16, 2020, 6:05 PM Brantley Coile <brantley(a)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(a)fourwinds.com> wrote:
>
> Steffen Nurpmeso writes:
>> Tony Finch wrote in
>> <alpine.DEB.2.20.2005142316170.3374(a)grey.csi.cam.ac.uk>uk>:
>> |Larry McVoy <lm(a)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
4:31 p.m.
New subject: v7 K&R C [really lexers]
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.
4:34 p.m.
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
13 Jun
13 Jun
9:24 p.m.
New subject: v7 K&R C [really lexers]
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(a)coraid.com> wrote:
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
"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(a)fourwinds.com> wrote:
Steffen Nurpmeso writes:
Tony Finch wrote in <alpine.DEB.2.20.2005142316170.3374(a)grey.csi.cam.ac.uk>uk>: |Larry
McVoy <lm(a)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 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
14 Jun
14 Jun
8:47 a.m.
New subject: v7 K&R C [really lexers]
scj(a)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
12:52 p.m.
New subject: v7 K&R C [really lexers]
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.
2:03 p.m.
New subject: v7 K&R C [really lexers]
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.
2:26 p.m.
New subject: v7 K&R C [really lexers]
Ralph Corderoy <ralph(a)inputplus.co.uk> wrote:
Hi Rich,
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
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.
2:48 p.m.
New subject: v7 K&R C [really lexers]
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.
15 Jun
15 Jun
1:12 a.m.
New subject: v7 K&R C [really lexers]
On Sun, Jun 14, 2020 at 03:48:19PM +0100, Ralph Corderoy wrote:
Hi Arnold,
Clem was kind enough to send the scan to me, and it's now here:
https://www.tuhs.org/Archive/Documentation/Papers/TuningUnixLex_Jacobson_US…
Cheers, Warren
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
1:29 a.m.
New subject: v7 K&R C [really lexers]
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_US…
John R. Levine might be a person to ask to see if he has a copy of
the paper.
Warren
6:06 a.m.
New subject: v7 K&R C [really lexers]
Warren Toomey <wkt(a)tuhs.org> wrote:
On Mon, Jun 15, 2020 at 11:12:30AM +1000, Warren
Toomey wrote:
I've just done so, by posting to comp.compilers.
Arnold
Clem was kind enough to send the scan to me, and
it's now here:
https://www.tuhs.org/Archive/Documentation/Papers/TuningUnixLex_Jacobson_US…
John R. Levine might be a person to ask to see if he has a copy of
the paper.
Warren
1404
days inactive
1455
days old
62 comments
27 participants
participants (27)
-
Adam Thornton -
arnold＠skeeve.com -
Brantley Coile -
Charles Anthony -
Clem Cole -
Dan Cross -
Dave Horsfall -
Derek Fawcus -
Greg A. Woods -
joe mcguckin -
John P. Linderman -
Jon Steinhart -
Larry McVoy -
Lars Brinkhoff -
Lawrence Stewart -
Michael Kjörling -
Paul Winalski -
Ralph Corderoy -
Rich Morin -
Richard Salz -
Rob Pike -
ron＠ronnatalie.com -
scj＠yaccman.com -
Steffen Nurpmeso -
Tony Finch -
Warner Losh -
Warren Toomey