[TUHS] early cc variable and function names

[TUHS] early cc variable and function names

[Noel Chiappa]

    > From: Greg 'groggy' Lehey <grog at lemis.com>

    > This is really an identifier issues

Probably actually a function of the relocatable object format / linker on the
machines in question, which in most (all?) cases predated C itself.

    > it's documented in K&R 1st edition, page 179:

Oooh, good piece of detective work!

	Noel

[TUHS] early cc variable and function names

[Ron Natalie]

The assembler could handle 8 case independent symbols.   C prepended an underscore to avoid any symbol conflicts.    If I recall the compiler allowed longer symbols but it just lost those letters after 7.

Amusingly an early IBM 370 compiler omitted prepending the underscore which lead to hilarity when you declared variables called things like R15.

On Oct 18, 2014, at 6:32 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:

>> From: Greg 'groggy' Lehey <grog at lemis.com>
> 
>> This is really an identifier issues
> 
> Probably actually a function of the relocatable object format / linker on the
> machines in question, which in most (all?) cases predated C itself.
> 
>> it's documented in K&R 1st edition, page 179:
> 
> Oooh, good piece of detective work!
> 
>    Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] early cc variable and function names

[Dave Horsfall]

On Sat, 18 Oct 2014, Ron Natalie wrote:

> Amusingly an early IBM 370 compiler omitted prepending the underscore 
> which lead to hilarity when you declared variables called things like 
> R15.

Holy snot!

-- 
Dave Horsfall (VK2KFU)
http://www.horsfall.org/spam.html (and check the home page)

[TUHS] early cc variable and function names

[Noel Chiappa]

    > From: jnc at mercury.lcs.mit.edu (Noel Chiappa)

    >> 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'.
    > ...
    > I'll see if I can dig them out tomorrow.

OK, there are three documents which sort of fall into this class. First,
there is something titled "New C Compiler Features", no date, available here:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/doc/cdoc/newstuff.nr

no date, but it appears to describe an early version of the so-called
'Typesetter C', mentioned in other documents, so this would be circa 1976 or
so.


There is a second document, untitled, no date, which I have not been able to
locate online at all. I scanned my hard-copy, available here:

  http://ana-3.lcs.mit.edu/~jnc/history/unix/CImprovements1.jpg
  ..
  http://ana-3.lcs.mit.edu/~jnc/history/unix/CImprovements5.jpg

From the content, it seems to be from shortly after the previous one, so say,
circa 1977.

Sorry about the poor readability (it looked fine on the monitor of the
machine my scanner is attached to); fudging with contrast would probably make
it more readable. When I get the MIT V6 Unix tapes read (they have been sent
off to a specialist in reading old tapes, results soon, I hope) I might be
able to get more info (e.g. date/filename), and machine-readable source.


Finally, there is "Recent Changes to C", from November 15, 1978, available
here:

  http://cm.bell-labs.com/cm/cs/who/dmr/cchanges.pdf
  
which documents a few final bits.


There is of course also Dennis M. Ritchie, "The Development of the C
Language", available here:

  http://cm.bell-labs.com/who/dmr/chist.html

which is a good, interesting history of 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 found several documents which are bits and pieces of this.

  http://ana-3.lcs.mit.edu/~jnc/history/unix/C_Backport.txt
  http://ana-3.lcs.mit.edu/~jnc/history/unix/V6_C.txt

Too busy to really clean them up at the moment.

	Noel

[TUHS] early cc variable and function names

[Noel Chiappa]

    > From: Mark Longridge <cubexyz at 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

[TUHS] early cc variable and function names

[John Cowan]

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

[TUHS] early cc variable and function names

[Larry McVoy]

On Thu, Oct 16, 2014 at 10:40:49PM -0400, John Cowan wrote:
> 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.

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 

[TUHS] early cc variable and function names

[John Cowan]

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 at 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] early cc variable and function names

[Larry McVoy]

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:
> 
> > 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 at 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

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

[TUHS] early cc variable and function names

[Clem Cole]

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 at 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 at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141017/2415f205/attachment.html>

[TUHS] early cc variable and function names

[random832]

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?

[TUHS] early cc variable and function names

[Larry McVoy]

On Fri, Oct 17, 2014 at 04:37:08PM -0400, random832 at fastmail.us wrote:
> 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?

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 

[TUHS] early cc variable and function names

[Mark Longridge]

Hi folks,

I've been looking at Unix v5 cc limitations.

It seems like early cc could only use variable and function names up
to 8 characters.

This limitation occurs in v5, v6 and v7.

But when using the nm utility to print out the name list I see
function test1234() listed as:
000044T _test123

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.

I hacked up a short program to test this:

main()
{
        test1234();
        test1235();
}

test1234()
{
        printf ("\nWorking");
}

test1235()
{
        printf ("\nAlso working");
}


This generated:
Multiply defined: test5.o;_test123

So it would seem that function names can only be 7 characters in
length. I am not sure if limitations of early cc were documented
anywhere. When I backported unirubik to v5 it compiled the longer
functions without any problem.

Did anyone document these sorts of limitations of early cc? Does
anyone remember when cc started to use function names longer than 7
characters?

Mark

[TUHS] early cc variable and function names

[Milo Velimirovic]

External names were limited to 7 (user-defined) characters because the compiler prepended the _ to them. Function names were always external in that era of C. Internal variables could be up to 8 characters. As for longer names, they were allowed but only the first 8 ( including the compiler supplied _ for external names) were signiicant.

I'll look for my documentation from v6.

 - Milo

On Oct 16, 2014, at 8:51 PM, Mark Longridge wrote:

> Hi folks,
> 
> I've been looking at Unix v5 cc limitations.
> 
> It seems like early cc could only use variable and function names up
> to 8 characters.
> 
> This limitation occurs in v5, v6 and v7.
> 
> But when using the nm utility to print out the name list I see
> function test1234() listed as:
> 000044T _test123
> 
> 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.
> 
> I hacked up a short program to test this:
> 
> main()
> {
>        test1234();
>        test1235();
> }
> 
> test1234()
> {
>        printf ("\nWorking");
> }
> 
> test1235()
> {
>        printf ("\nAlso working");
> }
> 
> 
> This generated:
> Multiply defined: test5.o;_test123
> 
> So it would seem that function names can only be 7 characters in
> length. I am not sure if limitations of early cc were documented
> anywhere. When I backported unirubik to v5 it compiled the longer
> functions without any problem.
> 
> Did anyone document these sorts of limitations of early cc? Does
> anyone remember when cc started to use function names longer than 7
> characters?
> 
> Mark
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] early cc variable and function names

[Dave Horsfall]

On Thu, 16 Oct 2014, Mark Longridge wrote:

> It seems like early cc could only use variable and function names up to 
> 8 characters.

In those days it took only the first seven and ignored the rest, 
prepending an underscore as you discovered.  I don't remember when longer 
names were recognised; for all I know it could've been around when 
pathnames could be longer than 14 chars (which I think may have been a 
BSDism).

-- 
Dave Horsfall (VK2KFU)
http://www.horsfall.org/spam.html

[TUHS] early cc variable and function names

[random832]

On Thu, Oct 16, 2014, at 22:21, Dave Horsfall wrote:
> On Thu, 16 Oct 2014, Mark Longridge wrote:
> 
> > It seems like early cc could only use variable and function names up to 
> > 8 characters.
> 
> In those days it took only the first seven and ignored the rest, 
> prepending an underscore as you discovered.  I don't remember when longer 
> names were recognised; for all I know it could've been around when 
> pathnames could be longer than 14 chars (which I think may have been a 
> BSDism).

For externals, it's a limitation of the PDP-11 a.out format. Other
systems may or may not have had the same limit or a different limit.

For VAX, 4BSD appears to use an "index into file string table", whereas
3BSD still has an 8-character string. I don't see any provision in the
4BSD linker for loading 3BSD binaries.

Filenames over 14 characters appear to have been introduced in 4.1BSD.

[TUHS] early cc variable and function names

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]


On Oct 17, 2014, at 7:35 AM, random832 at fastmail.us wrote:

> On Thu, Oct 16, 2014, at 22:21, Dave Horsfall wrote:
>> On Thu, 16 Oct 2014, Mark Longridge wrote:
>> 
>>> It seems like early cc could only use variable and function names up to 
>>> 8 characters.
>> 
>> In those days it took only the first seven and ignored the rest, 
>> prepending an underscore as you discovered.  I don't remember when longer 
>> names were recognised; for all I know it could've been around when 
>> pathnames could be longer than 14 chars (which I think may have been a 
>> BSDism).
> 
> For externals, it's a limitation of the PDP-11 a.out format. Other
> systems may or may not have had the same limit or a different limit.
> 
> For VAX, 4BSD appears to use an "index into file string table", whereas
> 3BSD still has an 8-character string. I don't see any provision in the
> 4BSD linker for loading 3BSD binaries.

As someone that wrote an assembler and a linker/loader for the VAX
back in the day (for my first CS class), I know that 4.2 definitely had
the string table, as did all the descendants that I encountered in the
field back during the great unix wars when I was instructed by my employer
to obfuscate certain symbols to “protect” IP.

Warner

> Filenames over 14 characters appear to have been introduced in 4.1BSD.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141017/6757e69a/attachment.sig>

[TUHS] early cc variable and function names

[arnold]

Warner Losh <imp at bsdimp.com> wrote:
> > For VAX, 4BSD appears to use an "index into file string table", whereas
> > 3BSD still has an 8-character string. I don't see any provision in the
> > 4BSD linker for loading 3BSD binaries.

I think System III or System V picked this up.

> > Filenames over 14 characters appear to have been introduced in 4.1BSD.

No, at 4.2 BSD with the Fast Filesystem.  (Maybe 4.1c or some such
already had the FFS, but the original 4.1 didn't...)

Arnold

[TUHS] early cc variable and function names

[Milo Velimirović]

On Oct 17, 2014, at 9:07 AM, arnold at skeeve.com wrote:

> Warner Losh <imp at bsdimp.com> wrote:
>>> For VAX, 4BSD appears to use an "index into file string table", whereas
>>> 3BSD still has an 8-character string. I don't see any provision in the
>>> 4BSD linker for loading 3BSD binaries.
> 
> I think System III or System V picked this up.
> 
>>> Filenames over 14 characters appear to have been introduced in 4.1BSD.
> 
> No, at 4.2 BSD with the Fast Filesystem.  (Maybe 4.1c or some such
> already had the FFS, but the original 4.1 didn't...)
> 
> Arnold
Right!
McKusick, et al. say that it came with the Fast Filesystem in 4.2 [1]

I recall a presentation at UW in Madison where he said, (paraphrasing from memory) We heard you guys. We included long file names in the Fast File System. (loud cheers)

 - Milo
[1] https://www.cs.berkeley.edu/~brewer/cs262/FFS.pdf

[TUHS] early cc variable and function names

[random832]

On Fri, Oct 17, 2014, at 10:07, arnold at skeeve.com wrote:
> Warner Losh <imp at bsdimp.com> wrote:
What's actually quoted is what I wrote.

> > > For VAX, 4BSD appears to use an "index into file string table", whereas
> > > 3BSD still has an 8-character string. I don't see any provision in the
> > > 4BSD linker for loading 3BSD binaries.
> 
> I think System III or System V picked this up.
> 
> > > Filenames over 14 characters appear to have been introduced in 4.1BSD.
> 
> No, at 4.2 BSD with the Fast Filesystem.  (Maybe 4.1c or some such
> already had the FFS, but the original 4.1 didn't...)

I was looking at 4.1c in the archive, sorry for not being clear.

[TUHS] early cc variable and function names

[Greg 'groggy' Lehey]

On Thursday, 16 October 2014 at 21:51:56 -0400, Mark Longridge wrote:
> So it would seem that function names can only be 7 characters in
> length. I am not sure if limitations of early cc were documented
> anywhere.

This is really an identifier issues, and it's documented in K&R 1st
edition, page 179:

  DEC PDP-11      7 characters, 2 cases
  Honeywell 6000  6 characters, 1 case
  IBM 360/370     7 characters, 1 case
  Interdata 8/32  8 characters, 2 cases

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141018/eafed5ba/attachment.sig>