djh@datlog.co.uk ( Dave Howorth ) (07/19/89)
In article <33148@apple.Apple.COM> Jonathan Patrick Leech writes: > How about if someone identifies the offending environments. >Presumably linkers introduced in the future will not suffer under the >6-character restriction, so people willing to flush the currently >offending systems from their porting base could work with a more >flexible limit. > Jon Leech (leech@apple.com) > Apple Integrated Systems I think this is an excellent idea, so lets do it! We can be positive by building a list open to all compilers which gives the implementation limits they impose. We should collect: - compiler/linker/platform name and version - operating system (UN*X, M*-DOS, other) - ANSI (yes/no) - internal name significant length - external name significant length - external name case significant (yes/no) - date for 31 character case significant external name version I am looking for this information for some work I am doing, and am prepared to collate and summarise to save net bandwidth. I would particularly welcome statements direct from compiler and hardware vendors! So mail me with what you know! Dave Howorth : djh@datlog.co.uk : +44 1 863 0383 Data Logic, Queens House, Greenhill Way, Harrow HA1 1YR, ENGLAND
shankar@hpclscu.HP.COM (Shankar Unni) (07/22/89)
> - date for 31 character case significant external name version
Hey, if we're going to change the world, why stop at 31 characters? Why
not make the symbols unrestricted in length (within reason - I can live
with 16384 :-)).
---
Shankar.david@psitech.UUCP (david Fridley) (07/23/89)
Requiring there to be a maximum name length is the sign of an inexperienced programmer. It is a simple process to tag each symbol with its length and realloc() the block untill it is big enough for any symbol, as long as there is enough memory (DOS) or enough virtual memory (real opreating systems). If any compiler, assembler, linker house really don't understand how to do this, I will personally post an explanation, and an example. Please, NO ARBITRARY LIMITS! david. DISCLAIMER: If it's important have a backup. If it ain't broke don't fix it. Proceed at your own risk. My oponions are MY own. Spelling does not count. My fondest dream is to leave this planet. -- david. DISCLAIMER: If it's important have a backup. If it ain't broke don't fix it. Proceed at your own risk. My oponions are my own.
henry@utzoo.uucp (Henry Spencer) (07/23/89)
In article <116@psitech.UUCP> david@psitech.UUCP (david Fridley) writes: >Requiring there to be a maximum name length is the sign of an inexperienced >programmer. It is a simple process to tag each symbol with its length and >realloc() the block untill it is big enough for any symbol... Claiming that "it's simple to do it right, so everyone should do it that way" is the sign of someone who never maintains other peoples' software. :-) As I understand it, the reason why ANSI C *encourages* unlimited-length names but *permits* a limit of 31 significant characters for internal names (we won't get into the external-name mess again...) is to make it easy to retrofit existing compilers that were not built for unlimited-length names. Nobody with any sense is going to implement a fixed limit in a new compiler, but s/8/31/g is a whole lot easier than changing fixed-length tables to use malloc, especially if you've got a tight deadline and a lot of more serious ANSI-compatibility problems to worry about. -- 1961-1969: 8 years of Apollo. | Henry Spencer at U of Toronto Zoology 1969-1989: 20 years of nothing.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bright@Data-IO.COM (Walter Bright) (07/25/89)
In article <1989Jul23.021533.27429@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: <In article <116@psitech.UUCP> david@psitech.UUCP (david Fridley) writes: <<Requiring there to be a maximum name length is the sign of an inexperienced <<programmer. It is a simple process to tag each symbol with its length and <<realloc() the block untill it is big enough for any symbol... <Nobody with any sense is going to implement a fixed limit in a new compiler, In the interminable quest for faster compilation, I've done a lot of profiling of my parser (Zortech). One of the major time sinks is pulling in the characters and stuffing them into the identifier array. The identifier array is therefore static because it's faster to access a static array than one that is accessed through a pointer. I did, however, bump up the size of the array to 127. Nobody seems to have run into that yet :-). If they do, I'll increase it to 256. The limit is just a #define in a header file. If you think I'm wrong about doing this to maximize performance, consider that my compiler is within 10% of TurboC's compilation speed, and it's a two pass compiler as opposed to TurboC's one pass. I've estimated that the two pass design costs about 25% in compilation speed. Real-world programming is always tradeoffs, no rule is absolute and no feature comes for free.
david@psitech.UUCP (david Fridley) (07/25/89)
> I did, however, bump up the size of the array to 127. Nobody seems to have > run into that yet :-). If they do, I'll increase it to 256. The limit is > just a #define in a header file. If you could make this a command line option, then I would be convinced it was a feature, and not a limitation. But, couldn't you start out with an array size of 127 and realloc it to 256 when you came across a symbol that long. It would take longer only if somebody used a longer symbol name, but it would still work right. > > If you think I'm wrong about doing this to maximize performance, consider > that my compiler is within 10% of TurboC's compilation speed, and it's > a two pass compiler as opposed to TurboC's one pass. I've estimated that > the two pass design costs about 25% in compilation speed. I work mostly with C to 68000 cross compilers. I would only like to point out that I am alot less sensative to compile time than I am to run time. I will only have to compile a few times to get my programs debugged, but they will be run many times. Perhaps a fast/slow command option would be appropriate. :) I have had a compiler manufacture tell me that compile time is more important than some runtime preformance features that I've looked for. All I can say is, I'm the customer. > > Real-world programming is always tradeoffs, no rule is absolute and no > feature comes for free. Absolutely! And the more of these tradeoffs you put in the hands of the customer the more features you have, and the fewer ARBITRARY LIMITS you have.