Conference turris::decc

You could just modify the header files so that the
extern_prefix pragmas include decc$  

For example, in time.h

#if __VMS_VER >= 70000000
#   if !defined _VMS_V6_SOURCE
#      ifdef __CAN_USE_EXTERN_PREFIX
#          pragma __extern_prefix __save
#          pragma __extern_prefix "__utc_"
#

Becomes:

#if __VMS_VER >= 70000000
#   if !defined _VMS_V6_SOURCE
#      ifdef __CAN_USE_EXTERN_PREFIX
#          pragma __extern_prefix __save
#          pragma __extern_prefix "decc$__utc_"
#

>>   <<< Note 2100.1 by CSC32::BLAYLOCK "If at first you doubt,doubt again." >>>



>>You could just modify the header files so that the
>>extern_prefix pragmas include decc$  

Thanks for the suggestion, but do we really want to tell customers
to modify our header files?

Jerry

>> Thanks for the suggestion, but do we really want to tell customers
>> to modify our header files?

No, we don't.

Re: .0

I'm not sure what you expect to get from /NAME=AS_IS.  I'll look into this a
little further and get back to you.

						Brian

I can get it compile and link cleanly via

	CC/DEFINE=_VMS_V6_SOURCE/NAME=AS_IS/PREFIX=ALL

The /PREFIX=ALL is needed typically for Unix-specific non-ANSI functions on
VMS, such as those included in unixlib.h, unistd.h, and unixio.h.

						Brian

RE: .4 but then as .0 claims:

If you add /define=_vms_v6_source, it
will compile and link cleanly, but you don't get the benefit of the
v7.0 utc functionality.

I'd suggest that this is a problem with the header files that
should be fixed by the (which one would be right?) RTL group.

R.

RE: .3

.>> Thanks for the suggestion, but do we really want to tell customers
.>> to modify our header files?
.
.No, we don't.

I disagree.  If someone comes up with a better solution then
that gets passed on to my customer. Waiting for a kit to 
fix a problem such as this does not help my customer.

But if you do not want to do a header modification, an example
shareable image that does the assist follows:

$ create testshr.mar
        .title  INTERFACE 1.0
.disable flagging
        .psect $$$CODE, exe, nowrt
__unix_getuid::
        .jsb_entry
        jmp     g^decc$__unix_getuid

__utc_ctime::
        .jsb_entry
        jmp     g^decc$__utc_ctime

__utc_time::
        .jsb_entry
        jmp     g^decc$__utc_time

__utctz_gmtime::
        .jsb_entry
        jmp     g^decc$__utctz_gmtime
        .end
$ macro testshr
$ link /share /map/full /cross testshr + sys$input: /option
IDENT="INTERFACE V1.0"
GSMATCH=LEQUAL, 1, 0
CASE_SENSITIVE=YES
SYMBOL_VECTOR = ( __UNIX_GETUID = PROCEDURE )
SYMBOL_VECTOR = ( __UTC_CTIME = PROCEDURE )
SYMBOL_VECTOR = ( __UTC_TIME = PROCEDURE )
SYMBOL_VECTOR = ( __UTCTZ_GMTIME = PROCEDURE )
SYMBOL_VECTOR = ( -
    SPARE, -
    SPARE, -
    SPARE, -
    SPARE, -
    SPARE, -
    SPARE, -
    SPARE, -
    SPARE, -
    SPARE, -
    SPARE, -
    SPARE -
    )
$
$ if f$search("time.c") .eqs. ""
$ then
$ create time.c
#include <time.h>
#include <unixlib.h>
main()
{
    char *c_time;
    const time_t *bintim;
    uid_t uid;
    struct tm *gtime;
    time_t seconds=0, *t_loc = 0;
    bintim = &seconds ;
    c_time = ctime(bintim);
    uid = getuid();
    gtime = gmtime(bintim);
    seconds = time(t_loc);
}

$ endif
$ cc /name= as_is time.c
$ link /map/ful/cross time + sys$input: /opt
sys$disk:[]testshr/share
$ exit

    I believe you can also link as follows:
    
    link test,alpha$library:vaxcrtl.olb/lib
    
    

    re: .0
    
    The undefined _UTC symbols are not due to /names=as_is, but are in fact
    due to not compiling /prefix=all.  The program in the basenote has a
    flaw in that the function "ctime" takes a pointer to a time_t, which
    you are passing as an indeterminate value.  
    
       ...
       const time_t *bintim;
       ...
       c_time = ctime(bintim);
       ...
    
    The variable bintim has not been initialized to a pointer value.
    
    Duane

I'm suspecting that the base note is not a real program and it's probably not a
problem in the real world code. As suggested in .8, bintim in uninitialized in
this program. DEC C will tell you that and will also tell you that t_loc is
likewise uninitialized.

Here's what I see on UNIX... you'll need the following change to compiler there:

#ifdef __unix__
#include <unistd.h>
#else
#include <unixlib.h>
#endif

% cc -check t.c
cc: Warning: t.c, line 8: The declaration of the function main has an empty
parameter list.  If the function has parameters, they should be declared here;
if it has no parameters, "void" should be specified in the parameter list.
main()
^
cc: Warning: t.c, line 8: The type of the function main defaults to "int".
main()
^
cc: Info: t.c, line 15: variable bintim is fetched, not initialized
    c_time = ctime(bintim);
-----------------------^
cc: Info: t.c, line 18: variable t_loc is fetched, not initialized
    seconds = time(t_loc);
-----------------------^


The same is available on VMS as /warn=enable=check

-Jeff

/*
**  Upon further investigation, the base note does demonstrate a compiler bug
**  when the pragma extern_prefix is used in conjunction with the qualifier
**  /NAMES=AS_IS.
**
**  It appears that the compiler uppercases both the prefix and the suffix 
**  prior to looking up the resulantant string in the name prefixing table.
** 
**  In the attached example, the extern_prefix is defined as "str" while the
**  routine name is defined as "len".  The results should be that a reference
**  to the routine "len" should be first transformed to "strlen" and then
**  further transformed to "decc$strlen".
**
**  When /NAMES=AS_IS is used, the "len" is transformed to "STRLEN" and then
**  not prefixed because the prefixing table contains "strlen".
*/

#if ((__DECC_VER < 50200000) && (!__DECCXX))
#   error "pragma extern_prefix not supported in this compiler!"
#endif

#ifdef __cplusplus
    extern "C" {
#endif

#pragma __extern_prefix __save
#pragma __extern_prefix "str"
int len(char *);
#pragma __extern_prefix __restore

#ifdef __cplusplus
    }
#endif

#include <stdio.h>

main () {

  char * example = "Example";
  printf ("The length of %s is %d\n", example, len(example));

}

>>         <<< Note 2100.10 by TLE::D_SMITH "Duane Smith -- DEC C RTL" >>>
>>                -< The user is right.  This is a compiler bug. >-

Sorry I haven't responded to this until now.  I was in training all
last week, and haven't been able to do a follow-up until now.

Since this is a compiler bug, are there any 'recommended' workarounds?
Ken Blaylock (thanks, Ken) has been gracious enough to provide two.
Which of those two would engineering prefer I give to the customer.
If neither, do you have one that you like better?

Also, my customer reported this as with the c++ compiler, and my testing
showed that it's also a problem with c.  As I pointed out previously,
I have posted a note in the c++ conference, and there is a reply to
that note that this will be followed by the discussion here.  My
question is do I need to do anything else to see that this is also
treated as a c++ compiler bug, or has that been taken care of.

Thanks,

Jerry

P.S.  I am assuming that C engineering has logged this and will be working
it for a future release, and that no further action is required from me.
Is this correct?

    The problem is that the function is not being prefixed by the compiler. 
    The solution given in .7 of linking against the "unprefixed" name
    object library is absolutely the most sound.  This library contains
    dispatch routines which cause "xxx" to pass control to "decc$xxx" and
    nothing more than that.
    
    Duane

The internal tracking number is CXXC_BUGS 4156.  The resolution will
most likely involve a compiler change to get the RTL name table
lookup done correctly, and also a documentation change to clarify
that the extern_prefix pragma can cause the resultant external name
to be all uppercased.  There's actually a bit of a consistency problem
here because currently C++ appears to force the names to uppercase,
and the C++ class libraries depend on this behavior.

According to both the DEC C User's Guide and Using DEC C++ (for VMS):

   All external names prefixed with a nonnull string using
   #pragma extern_prefix are converted to uppercase letters
   regardless of the setting of the /NAMES qualifier.

So this is simply a compiler bug where we fail to take into account
the upcasing specified by extern_prefix when we look for the name
in the RTL name table under /names=as_is (which has the names in
lowercase in the table).  Since RTL name table transformation
takes place after extern_prefix, presumably it will not be
considered a bug if the final name comes out in lowercase.

This effect can already be seen under /names=lower: when a name
formed by extern_prefix is found in the RTL map, it appears
in the .obj file in lowercase (along with any other transformation
specified by the RTL map).

Thanks.

I'll pass along the workaround in .7, and probably even write a stars
article to address this for future use.

Jerry

    
    The compiler bug posted in reply .10 has been corrected.  Duane has
    used this compiler and said it will correct the problem in .0.
    
    This correction should be included in V5.6 which will be going to
    field test shortly.
    
    						Ed