17 Oct
2014
17 Oct
'14
2:29 a.m.
From: Mark Longridge <cubexyz(a)gmail.com>
It seems like early cc could only use variable and
function names up to
8 characters.
This limitation occurs in v5, v6 and v7.
...
That seems to suggest that only the first 7 characters are significant,
but when looking at other sources they stated that one can use up to 8
characters.
The a.out symbol tables use 8-character fields to hold symbol names. However,
C automagically and unavoidably prepends an _ to all externals (I forget
about automatics, registers, etc - too tired to check right now), making the
limit for C names 7 characters.
I am not sure if limitations of early cc were
documented anywhere.
I remember reading the above.
Other limits... well, you need to remember that C was still changing in that
period, so limits were a moving target.
When I backported unirubik to v5 it compiled the
longer functions
without any problem.
ISTR that C truncated external names longer than 7 characters. Probably the
ones in that program were all unique within 7, so you won.
Did anyone document these sorts of limitations of
early cc?
I seem to recall at least one document from that period (I think pertaining
to the so-called 'Typesetter C') about 'changes to C'.
Also, I have started a note with a list of 'issues with C when you're
backporting V7 and later code to V6', I'll see if I can dig them out tomorrow.
Noel
17 Oct
17 Oct
2:40 a.m.
New subject: early cc variable and function names
Noel Chiappa scripsit:
The a.out symbol tables use 8-character fields to hold
symbol names. However,
C automagically and unavoidably prepends an _ to all externals (I forget
about automatics, registers, etc - too tired to check right now), making the
limit for C names 7 characters.
The _ was only for externals, including all procedure names. It prevented
collisions with names introduced into the assembly-language source or
in libc.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
A male Jang appeared at my side. "Get a grip on yourself," he said.
"Get a grip on your graks," I suggested. --Tanith Lee, Drinking Sapphire Wine
2:52 a.m.
New subject: early cc variable and function names
On Thu, Oct 16, 2014 at 10:40:49PM -0400, John Cowan wrote:
Noel Chiappa scripsit:
This is perhaps a side note but I believe all structure fields shared a
namespace. So stat.size and whatever.size were not allowed, they collided.
So we got sb.st_size which I personally love and wish it were still like
that.
xyz.size
abc.size
foobar.size
What are the types of those structures?
abc.st_size
Huh, abc is a struct stat.
I get that it was a bug and needed to be fixed but I wish that everyone
still pretended that it was one namespace, makes code so much easier to
read.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
The a.out symbol tables use 8-character fields to
hold symbol names. However,
C automagically and unavoidably prepends an _ to all externals (I forget
about automatics, registers, etc - too tired to check right now), making the
limit for C names 7 characters.
The _ was only for externals, including all procedure names. It prevented
collisions with names introduced into the assembly-language source or
in libc.
3:46 a.m.
New subject: early cc variable and function names
Larry McVoy scripsit:
xyz.size
abc.size
foobar.size
What are the types of those structures?
You can't tell because the names are meaningless. With more meaningful
names, it's usually possible to see what the type must be.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
I don't know half of you half as well as I should like, and I like less
than half of you half as well as you deserve. --Bilbo
3:54 a.m.
New subject: early cc variable and function names
So I've been doing C programming since the early 80's and leading
people doing that for at least 20 years, huh, more like 25 years.
As much as I wish people did what you suggest, they don't. And I
mean really good people, top 1%.
So I like the type_name style.
As with many things, I may like it but I don't always get it.
On Thu, Oct 16, 2014 at 11:46:18PM -0400, John Cowan wrote:
Larry McVoy scripsit:
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
xyz.size
abc.size
foobar.size
What are the types of those structures?
You can't tell because the names are meaningless. With more meaningful
names, it's usually possible to see what the type must be.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
I don't know half of you half as well as I should like, and I like less
than half of you half as well as you deserve. --Bilbo 
7:41 p.m.
New subject: early cc variable and function names
Larry - AMEN.
The key is that in the old days it was much easier to glance and code and
know which struct or union was being examined. Today, that context is lost
and I have to think more about what the type of the ptr is. Yes the
>compiler<< knows, but I as the random
programmer reading the code later
do not.
Larry and my experiences with very, very good programmers is the same.
Clem
On Thu, Oct 16, 2014 at 11:46 PM, John Cowan <cowan(a)mercury.ccil.org> wrote:
Larry McVoy scripsit:
xyz.size
abc.size
foobar.size
What are the types of those structures?
You can't tell because the names are meaningless. With more meaningful
names, it's usually possible to see what the type must be.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
I don't know half of you half as well as I should like, and I like less
than half of you half as well as you deserve. --Bilbo
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
8:37 p.m.
New subject: early cc variable and function names
On Thu, Oct 16, 2014, at 22:52, Larry McVoy wrote:
abc.st_size
Huh, abc is a struct stat.
I get that it was a bug and needed to be fixed but I wish that everyone
still pretended that it was one namespace, makes code so much easier to
read.
I'm not sure what your design is that you're more than a screen away
from either its declaration, a stat call, or the fact that it's got size
_and_ mode _and_ mtime etc.
And if you do that, why stop there? Why not require the type to be
repeated to dereference any pointer?
while(*x == 0)
is x a pointer to int, to char, to another pointer, etc?
8:42 p.m.
New subject: early cc variable and function names
On Fri, Oct 17, 2014 at 04:37:08PM -0400, random832(a)fastmail.us wrote:
On Thu, Oct 16, 2014, at 22:52, Larry McVoy wrote:
Hey, everyone is welcome to their own opinion and it doesn't have to match
mine. I review a lot of code, a lot of code that I didn't write. Lots of
times the review is in a web browser that doesn't know how to tag to the
definition. Sure I can clone the repo and make tags and tag to it but for
small reviews there is no need.
I do a bunch of code reviews every day. foo.size is a lot less helpful
than foo.vfs_size or whatever.
Your mileage may vary, where I work we optimize for the reader not for
the writer. That's how it is when you work for me. When I work for
you then your rules win :)
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
abc.st_size
Huh, abc is a struct stat.
I get that it was a bug and needed to be fixed but I wish that everyone
still pretended that it was one namespace, makes code so much easier to
read.
I'm not sure what your design is that you're more than a screen away
from either its declaration, a stat call, or the fact that it's got size
_and_ mode _and_ mtime etc.
And if you do that, why stop there? Why not require the type to be
repeated to dereference any pointer?
3479
days inactive
3479
days old
7 comments
5 participants
participants (5)
-
Clem Cole -
jnc＠mercury.lcs.mit.edu -
John Cowan -
Larry McVoy -
random832＠fastmail.us