bright@dataio.Data-IO.COM (Walter Bright) (10/15/87)
In article <1298@wyszecki.munsell.UUCP> jwf@munsell.UUCP (Jim Franklin) writes: >The proposed ANSI C limit of 6 characters on external symbols is >completely bogus. >The "justification" given for the limit is that ANSI C needs to be >supported by many vendors in order for it to succeed as a standard, and >there exists a variety of obsolete compilers and linkers that will only >support 6 character externals. Compiler vendors have to do a lot of work to convert K+R compilers into ANSI C compilers. Since they will have to do this work anyway, what's the big deal about fixing the linker so it will handle 32 character names? I don't understand the problem that the vendors have. If the vendors don't have control over the linker, they can write their own. I know from experience: for Datalight C, I was finally forced to provide my own linker because of various problems with the Microsoft linker. It turned out to be much easier than I expected, and most of the other compiler vendors have done the same thing. As for interim solutions, a vendor can say that they are fully ANSI compatible, except they only have 6 char externals. Having to say this will cause customer pressure on them to fix their software. As for my projects (which run on PC's to Vaxes to 68000s to 32032s), I assume 31 char limits, and have not run into a problem. PDP-11s are dead for serious development anyway. Assume 31 char limits, and refuse to port your software to a machine if it only has 6 char limits. Take a stand!
guy%gorodish@Sun.COM (Guy Harris) (10/16/87)
> Compiler vendors have to do a lot of work to convert K+R compilers into > ANSI C compilers. Since they will have to do this work anyway, what's the > big deal about fixing the linker so it will handle 32 character names? It's not just "fixing the linker"; it may also be fixing the object file format. It is certainly possible to do so in *some* cases (for instance, COFF was extended to handle long symbol names); however, I don't know how much effort would be involved if, say, IBM wanted to extend the OS/360-and-successors object file format. (Assuming it hasn't already been done.) > I don't understand the problem that the vendors have. If the vendors don't > have control over the linker, they can write their own. This may be true in, say, the MS-DOS world (I get the impression that linkers have proliferated like rabbits there); I don't know how much extra work it would be, though, to do a new linker for OS/360-and-successors, nor do I know how usable such a linker would be if it couldn't handle old-style object files and libraries. Also note that inconveniences to C programmers may not necessarily be sufficient to get a vendor to upgrade their linker. I don't know that all machines are going to experience an explosion in the availability of software just because people are more willing to write in C for that machine. > Assume 31 char limits, and refuse to port your software to a machine if > it only has 6 char limits. Take a stand! This is a perfectly rational position, as long as the person holding it doesn't take it as given that this will cause everybody to update their object file formats. Nobody says that *every* programmer using C *must* write to the lowest common denominator; if you're writing software for some market where all linkers support long names, and don't care about other markets, there's no point in unnecessarily constraining yourself. The people complaining about the ANSI C standard's minima here are too low should note that the lives of many programmers (in fact, probably *most* programmers) out there will not be affected in the least by this aspect of ANSI C; they will continue to be able to use longer object names. They should also note that it is not a given that getting the ANSI C committee to raise this minimum will cause every C implementation out there to raise *its* minimum. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
franka@mmintl.UUCP (Frank Adams) (10/21/87)
In article <1386@dataio.Data-IO.COM> bright@dataio.UUCP (Walter Bright) writes: >In article <1298@wyszecki.munsell.UUCP> jwf@munsell.UUCP (Jim Franklin) writes: >Compiler vendors have to do a lot of work to convert K+R compilers into >ANSI C compilers. Since they will have to do this work anyway, what's the >big deal about fixing the linker so it will handle 32 character names? When a C compiler is rewritten to conform to the standard, only the C users are inconvenienced by the transition. Since they are presumably the beneficiaries from standardization, this is fine. When the linker for an operating system is changed, *all* the developers are impacted. In the case of the principle mainframe operating system in the world, the C users are a tiny fraction of that population. >I don't understand the problem that the vendors have. If the vendors don't >have control over the linker, they can write their own. I know from >experience: for Datalight C, ... This is realistic for micro-computers, but not really for minis. In the mainframe environment, forget it. Even for minis, people want to link together programs written in different languages. This won't work if each language has its own linker. (The time is coming when this won't do in the micro arena, either.) -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
fyl@ssc.UUCP (Phil Hughes) (10/22/87)
In article <1386@dataio.Data-IO.COM>, bright@dataio.Data-IO.COM (Walter Bright) writes: > In article <1298@wyszecki.munsell.UUCP> jwf@munsell.UUCP (Jim Franklin) writes: > >The proposed ANSI C limit of 6 characters on external symbols is > >completely bogus. > Compiler vendors have to do a lot of work to convert K+R compilers into > ANSI C compilers. Since they will have to do this work anyway, what's the > big deal about fixing the linker so it will handle 32 character names? I agree a reasonable limit (like 32 characters) would be nice but so would a lot of other changes in C. I had the same opinion about a few other desirable changes until I was talking to Larry Rosler (who, at the time, was the ATT member on the ANSI C committee) about them. The ANSI charter requires that they "document common usage" rather than do it right. In other words, you cannot invent a new language with an ANSI standard but only document an existing one. When there is a conflict in common usage you have to weigh the inconvenience of one choice over the amount of broken existing code for another. This is why there are some non-progressive decisions on the part of the ANSI committee. I have met five of the committee members and have been an observing member of the committee for a couple of years. Although I don't always like the final decisions from my personal point of view, I am impressed with the dedication of the committee members in fulfilling their charter. Now, for C++, ... -- Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX or 527-3385 ...!uw-beaver!tikal!ssc!fyl
blarson@skat.usc.edu (Bob Larson) (10/23/87)
I realize this is too late to seriously be considered for the version
of ANSI C currently under development, but couldn't systems
constrained to using an obsolete linker (6 char external) have an
intermeadiate pass between the C compiler and the linker to merge all
C routines into a single linker input file with unique symbols? This
extral linking pass could allow long C symbols to be equated to short
non-c symbols for allowing C to interface with other languages. Sure
this is slow and acward, but it only penalizes those who refuse to
provide a reasonable linker...
--
Bob Larson Arpa: Blarson@Ecla.Usc.Edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson blarson@skat.usc.edu
Prime mailing list (requests): info-prime-request%fns1@ecla.usc.edurwhite@nusdhub.UUCP (Robert C. White Jr.) (10/23/87)
In article <4807@oberon.USC.EDU>, blarson@skat.usc.edu (Bob Larson) writes: > of ANSI C currently under development, but couldn't systems > constrained to using an obsolete linker (6 char external) have an > intermeadiate pass between the C compiler and the linker to merge all... As I understand it, many of them do. As far as ANSI's input on the subject I think there job does NOT include telling developers and others how to _implement_ the standard. With the standard in place as it is now, any who care to may do just that. To require it in the standard would be murder. Rob.
nobody@ism780c.UUCP (Unprivileged user) (10/24/87)
>>I don't understand the problem that the vendors have. If the vendors don't >>have control over the linker, they can write their own. I know from >>experience: for Datalight C, ... > >This is realistic for micro-computers, but not really for minis. In the >mainframe environment, forget it. Even for minis, people want to link >together programs written in different languages. This won't work if each >language has its own linker. (The time is coming when this won't do in the >micro arena, either.) > >Frank Adams Ah, but it can work. I once wrote a compiler for an extended version of Pascal. The compiler allowed very long identifiers. The host operating system linker allowed six character names using upper case only. Never the less the Pascal program could reference routines in the system library. The way this worked was that a 'Binder' program was supplied along with the compiler. The binder linked all the Pascal objects with their long external names. If there were any unresolved references, the output of the binder was handed to the host system's linker. And Lo, an executable module resulted. Cleary, if a FORTRAN program referenced a Pascal subroutine, then THAT Pascal subroutine name was restricted by the FORTRAN naming rules. BTW. I also supplied an 'librarian' so that libraries of Pascal subroutines could be maintained. The effort to do the binder and librarian represented about 10% of the total compiler effort. And how did the debugger reference the Pascal variables? Simple, The host system did not have one. (Is this true for all systems with 6 character linkers?) Marv Rubinstein
franka@mmintl.UUCP (Frank Adams) (10/30/87)
In article <7637@ism780c.UUCP> marv@ism780.UUCP (Marvin Rubenstein) writes: |[I wrote:] |>[Somebody wrote:] |>>If the vendors don't have control over the linker, they can write their |>>own. |> |>people want to link together programs written in different languages. | |Ah, but it can work. I once wrote a compiler for an extended version of |Pascal. The compiler allowed very long identifiers. The host operating |system linker allowed six character names using upper case only. ... [A] |'Binder' program ... linked all the Pascal objects with their long external |names. If there were any unresolved references, the output of the binder was |handed to the host system's linker. Fine so far. But my hypothetical developer also wants to use Ada, which supports longer character names, and it has it's own linker, too. Now what do we do? At the very least, Pascal and Ada aren't going to be able to access each other's long variable names. You're also going to have trouble if you have a library written in Pascal, and want to call members from FORTRAN. Not an insoluable problem, but inconvient and tricky. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
rustcat@russell.STANFORD.EDU (Vallury Prabhakar) (11/08/87)
In article <2530@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: [...other references deleted..] >You're also going to have trouble if you have a library written in Pascal, >and want to call members from FORTRAN. Not an insoluable problem, but >inconvient and tricky. In this context, one of my friends wrote a Pascal interface for the set of GKS routines (which are in Fortran) for a VMS system. Didn't seem to have too much trouble doing it. On the other hand, I tried linking C modules to Fortran subroutines a while ago, for the same purpose. Linking routines which only juggled around with numbers was fine, but handling strings was not all that easy. Again, I guess this would vary from system to system. -- V