Re: name mangling advice requested

  John R Levine <johnl@iecc.com>
asked for comments on name mangling in various languages, and specifically


>> For example, back in ancient days, did COBOL programmers who were used to
variable names like weekly-pay-before-deducting-baksheesh really put up
with six or eight character linker limits ?
<<


I can comment on IBM mainframe COBOL, where there is, even still, very
little need for name mangling or for lengthy external names.


Program names do not get reused for different invocation patterns, and
indeed, there is no means of typing the input parms to a COBOL
submodule. This is a common source of error. Even the number of
procedure arguments is not set by any definition or declaration.


About the only thing this laxity has going for it is that sketching
the mainline is a snap. A higher level programs can initially be coded
as terribly as you like, ... code calls to anything, ... pass
anything. Just don't execute it.


More seriously, COBOL harkens from a day when interfaces were layed
out with an exactitude that is alien to modern design philosophy.


In the new world it is basically up to the called service to determine
the details of response to an invocation. In the old world, the map
of every single detail of an interface was the essence of the
call. COBOL comes from a time, actually, when there was not such a
keen distinction between data design and function design (although it
serves such a later world quite well).


Although data names in COBOL do seem excessively long to those not
accustomed to their use, all of that typically lasted no longer than
the compile. Humongous layouts just got reduced to an address that
was passed to a submodule as a base address. Driver and submodule had
to aggree upon the displacement and data type of all detailed fields
(of course, you could pass multiple addresses).


But the details were never referenced by those 30-character data names
within the interfaces. higher and lower level modules were (and still
are) free to use entirely different symbolic names for data items.


The use of COBOL copybooks is analogous to C language include
statements, but usually only to the extent that COBOL layouts are like
C structs. In C you could use two distinct functionally identical
structs in a caller and a service module, but you probably would not
want to.


In my opinion, the use of two different copybooks, or two different
hard coded layouts, is dreafully common in COBOL shops, and is a source
of serious error.


But there are no function prototypes in COBOL, as it stands today.
The number of arguements to a submodule, their type, and even there
raw length is not cross checked at compile time of invoker or of
submodule.


Program names are limitted to eight characters and the argument typing
is never mangled into the module name. Eight character linkage names
are thus quite adequate.


Obviously, this program facility undergoes gyrating pressure when
attempting to harness it to object oriented facilities. I will let
those who are more current on the advancing PC based object oriented
COBOLs comment on system construction there.


Even as IBM stretches the modern mainframe COBOL compilers into the
OS/390 world, the COBOL program model remains very flat, ... as far as
the coder is aware.


The COBOL sevice routines and the LE/390 functions are increasingly
handled as vectored transfers that are, thankfully, utterly
transparent to application programmers.


The 'common' functions available to COBOL and to other languages in
the Language Environment include, so far on the COBOL side, a
miniscule list or abject simplicity, ... such as date, time, and
arithmetic average. The small amount of variablity in these services
certainly does not necessitate name space enumeration such as is
possible with name mangling.


Although that could well be going on in the service libraries, the
vectored links hides it from COBOLers.


So, your general request for


"...reports of how names are mangled on other C++ compilers,as well as
other languages "


might also be pursued with a parallel inquiry, that I would
respectfully like to add to your post. What languages actually
necessitate program function enumeration on an order larger than eight
character names?


There is a diffenrece between simply allowing long names as a
component management convenience, and actually necessitating it to
meet the guaranteed behavior of the language discipline.


Where did this mangling fanangling originate anyway? SIMULA?


Is there anything other than function arguement typing that compells
the long names? (Yes I know that if you simply wish to have a long
list of external names you could want long names to ease the task of
keeping track of the meaning of data items or entry points).


Anyway, a person could hold the opinion that COBOL needs long external
names. But very large projects have survived without them for some
time.


One other comment that would be relevant to compiler writers. COBOL in
mainframe shops is actually several different languages.


COBOL has a syntax escape mechanism that goes something like this


EXEC alternate-syntax-token
      blah, blah, blah
END-EXEC.


These erzatz erpressions bring in magnificent products like CICS, IMS,
and DB2, which as most readers of this newsgroup will recognize are
teleprocessing and database services. The alternate-syntax-token would
either be CICS, DLI or SQL.


These statements are parsed by pre-processors which turn the origianl
statements into comments, and emit native COBOL language statements
(usually CALLs to function laden entry points). To get IMS services
COBOL calls 'CBLTDLI' (COBOL to Data Language Interface), for CICS it
is 'DFHEI' (Data Facility Hierarchical Execution Interface). These are
single entry points with massive enumerated function lists, in
contrast to lenthy lists of name-mangled-functions with a few
distinguishing arguements.


Each of the three named products has its own syntax (DB2, being SQL,
is a 'standard' syntax).


The key to understanding this is the preprocessing parser technology
only recognizes certain legal syntaxes. The productions of the rules
(evidently) just encodes a robust funtion (call it the
'message'). These things can be very esoteric literals involving
unprintable characters. These are as obtuse as rune stones to
COBOLers. They could care less what they mean.


So, although COBOL does suffer more errors than it needs to due to the
lack of function declaration feature in the language, a number of the
crucial products are preprocessed with rules that impose an analogous
set of restrictions on standard service invocations. And the obsession
with data layouts, and strong tradition of use of copybooks, goes some
distance towards regulating interfaces between the application drivers
and submodules unique to any given COBOL shop.






Some COBOL systems have real large program structures, but COBOL shops
remain data specification shops by and large. The large program
stcuctures, and consequent program name list, are really just a divide
and conquer strategy.


What is done with elegant languages like C/C++ using distinct argument
list for apparently the same function name, is done in COBOL simply by
different program name, or with the use of functin-codes or
command-codes.


In this reqard the COBOL REDEFINES feature is a source of abuse and
COBOLesque elegance. A REDEFINES is like a C language
[Message was truncated here. -John]


Robert Rayhawk
RKRayhawk@aol.com
[No language ``needs'' longer than eight character externals, since
you could always write a name mangling system external to the linker
that mangled everything down to eight characters. But between
descriptive names and type name mangling to encode the types in the
name, long names in the linker are definitely useful. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.