dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/01/88)
In article <1988Sep29.185014.29260@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: (about my proposal that a custom port-processor be used to shorten long external names) >And the >postprocessor has to scan all the libraries, to prevent name conflicts >with them. And the object modules and libraries can't be postprocessed >until linking time. How, precisely, is this different from defining a >new object-module format and writing a new linker? We are assuming that the standard system linker can't handle long names, so the standard libraries will only contain short (6-char or less) symbols. Therefore no special processing is needed for the libraries. My proposal does assume a new object-module format, one that contains long symbols. The post-processor does no linking. It simply takes each object custom-format object module from the C compiler and translates it to a system-format object module. It is possible for the post-processor to take a long symbol and convert it to a short symbol that conflicts with a symbol already in a library. There are ways of preventing this. If a naming scheme can be found that guarantees the creation of names not already in any standard library, the problem is solved. At the very least, given a list of names reserved by ANSI, it should be possible to avoid conflicts with names of standard C functions. If no such naming scheme is possible, users of the system (programming in any language) are already in serious trouble, since they can never be sure that one of their global symbols won't conflict with a library symbol. But we can still handle this situation. The post-processor can be run once each time the system libraries are updated, to scan them and make a master list of all symbols in these libraries. Then, each time the user's object modules are processed, the post-processor avoids using symbols that are already in this master list. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
peter@ficc.uu.net (Peter da Silva) (10/03/88)
In article <4162@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > But we can still handle this situation. The post-processor > can be run once each time the system libraries are updated, to scan > them and make a master list of all symbols in these libraries. Then, > each time the user's object modules are processed, the post-processor > avoids using symbols that are already in this master list. What about local libraries written in something other than 'C'. You can still do it with a local format. Here's how. Compile 'C' modules into local-format objects. These objects have long-name externals. Link these modules together into a global-format object. Any unsatisfied long names at this point are an error. You may have to include the 'C' runtime library here to allow for sprintf and strrchr. Link these modules with your Fortran and PL/I modules. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net