[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hylndr::dclreview

Title:DCLREVIEW
Moderator:HYLNDR::SYSTEM
Created:Sun Apr 19 1987
Last Modified:Fri May 23 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:773
Total number of notes:5391

767.0. "Additions to /NAMES for DEC C/C++" by DECC::VOGEL () Fri Apr 04 1997 17:07

    Product: DEC C and C++ for OpenVMS

    Contact Name: Ed Vogel
    E-Mail Address: DECC::VOGEL
    DTN: 381-2668

    Additions to the /NAMES qualifier in DEC C and C++.

    Command Summary:

    	Extend the /NAMES qualifier of the DEC C and C++ to allow
	for external names which are greater than 31 characters
	to be mangled instead of truncated.  A mangled name will
	consist of the first 24 characters of the name followed
	by a 7 character CRC (Cyclic Redundancy Check) which was
	computed by looking at the full name.  Currently DEC C/C++ 
	issue a warning an truncate the name to 31 characters.  

    Justification:

	Users who write applications for a number of platforms find 
	that OpenVMS has the shortest external name space of all their 
	platforms.  This requires them to keep external names unique
	to 31 characters.  External name mangling will remove this
	limitation.

   
    Details:

	The current /NAMES qualifier options are:

	    /NAMES=UPPERCASE (the default) converts external names to uppercase.
	    /NAMES=LOWERCASE converts external names to lowercase.
	    /NAMES=AS_IS leaves the case of external names unchanged.

        I propose to change /NAMES so that in addition to accepting one
	of the three values above it will also accept one of:

	    /NAMES=TRUNCATE (the default) truncates long external names
	    /NAMES=MANGLE mangle long external names.

    Note that for C++ this change would only impact external names
    declared within an extern "C" block.

T.RTitleUserPersonal
Name
DateLines
767.1GEMEVN::FAIMANWandrer, du M�der, du bist zu HausMon Apr 07 1997 10:329
May I suggest that MANGLED and TRUNCATED would be better?

UPPERCASE and LOWERCASE might be either adjectival forms or verbs; but AS_IS is
clearly adjectival, so I think the new keywords ought to be as well.

That is, you have uppercase names, lowercase names, or "as-is" names; and you
have mangled names or truncated names.

	-Neil
767.2DECC::VOGELMon Apr 07 1997 10:4610
    
    Re .1 - Neil,
    
>May I suggest that MANGLED and TRUNCATED would be better?

    Yes.  Thanks.
    
    	Ed
    
    
767.3DECCXX::COLEENThu Apr 10 1997 17:5819
I'd like to propose the keyword "UNIQUELY_SHORTENED"  (AHH!) instead
of "MANGLED".  In C++, function names are already "mangled".  "Mangled"
in DEC C++ means: Add type encoding to the name to support overloading.

We have a demangler tool that will give you the signature of a name,
for example:

%demangle
f__1CXi
(yields) C::f(int)
%

Calling these CRC'ed names "MANGLED" is confusing.

(NOTE: Please think of a better name than "UNIQUELY_SHORTENED").

Thanks,
Coleen
767.4Other suggestionsDECC::VOGELThu Apr 10 1997 21:526
    
    Kevin Harris has suggested CRC_SHORTENED.  I would also consider
    ENCODED or CRC_ENCODED or CRC_CODED.
    
    					Ed
    
767.5TLE::REAGANAll of this chaos makes perfect senseFri Apr 11 1997 16:146
    CRC* doesn't stick too well with me since that is just exposing how
    you shortned them.  Most people don't care if you used a CRC or a
    crystal ball to figure out the new name.  ENCODED seems OK as would
    ENCRYPTED.
    
    				-John
767.6They're not encryptedCXXC::REPETERich Peterson 381-1802 ZKO2-3/N30Thu Apr 17 1997 17:2211
I think encrypted is clearly inappropriate - the idea is to make the
name unique without making it any more cryptic than absolutely necessary.

To that end, I also think that CRC_SHORTENED CRC_ENCODED is preferable
to ENCODED.  While you might (and did) say that CRC_ just exposes the
algorithm, in practice I think it also conveys the purpose of the
option in a small number of characters.  The intent is not to encrypt
(security-related) or encode (to carry additional information that wasn't
already present), but to assure uniqueness when part of the original
information is removed.  I think CRC_SHORTENED captures that the best,
with CRC_ENCODED a close second.
767.7GEMEVN::FAIMANWandrer, du M�der, du bist zu HausFri Apr 18 1997 10:011
Why not SHORTENED?
767.8QUARK::LIONELFree advice is worth every centTue Apr 22 1997 09:504
Don't use "ENCRYPTED" - first of all, it's inaccurate - second, it will raise
red flags all over the place with people concerned with export controls.

			Steve
767.9TLE::REAGANAll of this chaos makes perfect senseTue Apr 22 1997 17:055
    Yeah, I guess encrpyted isn't good.  However, everything I see CRC
    I think of the large book of chemical/mathematical/etc. formula
    and data that is in my bookcase at home.
    
    				-John
767.10CXXC::REINIGThis too shall changeTue Apr 22 1997 19:153
    Does any other C compiler do this?  What names do they use.
    
                                        August
767.11QUARK::LIONELFree advice is worth every centWed Apr 23 1997 16:243
ENCODED works for me.

			Steve
767.12Why not?CXXC::REPETERich Peterson 381-1802 ZKO2-3/N30Tue Apr 29 1997 17:4223
RE .7:

> Why not SHORTENED?

Good question.  My first reaction would be that it might imply
truncation.  But since TRUNCATED is the alternative/default,
I guess it should be pretty clear that the shortening would
involve something other than truncation.  I think SHORTENED
is the clear winner.

RE .9:

Regarding the Chemical Rubber Company's famous handbook, I
might be inclined to agree except that I encountered CRC
with the intended meaning in an IBM manual on 9-track tape
formats before my first encounter with the presentation of
all physical knowledge in tabular form.

RE .10:

Regarding other compilers, I'm not aware of any that have this
kind of problem.  VMS has the shortest limit of any of the
platforms our customers use.