From: milov@cs.uwlax.edu (Milo Velimirovic)
Subject: [TUHS] early cc variable and function names
Date: Thu, 16 Oct 2014 21:20:23 -0500 [thread overview]
Message-ID: <07F8EFBD-054E-4296-BDE9-879F6C36A649@cs.uwlax.edu> (raw)
In-Reply-To: <CADxT5N4x_q8zreY_ky7SwNn2OqK07OnqO+uUAm_pRfALo-5iZA@mail.gmail.com>
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
next prev parent reply other threads:[~2014-10-17 2:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-17 1:51 Mark Longridge
2014-10-17 2:20 ` Milo Velimirovic [this message]
2014-10-17 2:21 ` Dave Horsfall
2014-10-17 13:35 ` random832
2014-10-17 13:44 ` Warner Losh
2014-10-17 14:07 ` arnold
2014-10-17 14:22 ` Milo Velimirović
2014-10-17 19:29 ` random832
2014-10-18 7:25 ` Greg 'groggy' Lehey
2014-10-17 2:29 Noel Chiappa
2014-10-17 2:40 ` John Cowan
2014-10-17 2:52 ` Larry McVoy
2014-10-17 3:46 ` John Cowan
2014-10-17 3:54 ` Larry McVoy
2014-10-17 19:41 ` Clem Cole
2014-10-17 20:37 ` random832
2014-10-17 20:42 ` Larry McVoy
2014-10-17 16:11 Noel Chiappa
2014-10-18 10:32 Noel Chiappa
2014-10-18 23:03 ` Ron Natalie
2014-10-18 23:11 ` Dave Horsfall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=07F8EFBD-054E-4296-BDE9-879F6C36A649@cs.uwlax.edu \
--to=milov@cs.uwlax.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).