Start rationalizing Unix-to-VMS file spec conversion code.

Back in 360732b5267d5dfef32b932bf13ceebc6683df74, we started using
an experimental new conversion routine that had been designed for
a CRTL feature called POSIX-compliant pathnames but at this point
was added as a jumping-off place halfway through the existing code
for converting Unix-format file specifications to VMS format. But
only for newer versions of VMS and only when a different and
unrelated feature called Extended Filename Syntax (EFS) had been
enabled.

But this newer implementation (somewhat inauspiciously named
posix_to_vmsspec_hardway) is less complete and more buggy than the
older implementation, and it imposes expectations that have nothing
to do with EFS, not to mention making for a larger, version-
specific support matrix.

So for now go back to the older, better-tested (though imperfect)
version and simplify the differences made by invoking EFS.  None
of this makes any difference at all unless non-default CRTL
features have been enabled.

1 files changed, 0 insertions, 11 deletions

diff --git a/vms/vms.c b/vms/vms.c
index 95b69a97e0..4f69ec52f7 100644
--- a/vms/vms.c
+++ b/vms/vms.c
@@ -8467,17 +8467,6 @@ static char *int_tovmsspec
       }
   }
 
-/* If EFS charset mode active, handle the conversion */
-#if __CRTL_VER >= 80200000 && !defined(__VAX)
-  if (decc_efs_charset) {
-    posix_to_vmsspec_hardway(rslt, rslt_len, path, dir_flag, utf8_flag);
-    if (vms_debug_fileify) {
-        fprintf(stderr, "int_tovmsspec: rslt = %s\n", rslt);
-    }
-    return rslt;
-  }
-#endif
-
   if (*(dirend+1) == '.') {  /* do we have trailing "/." or "/.." or "/..."? */
     if (!*(dirend+2)) dirend +=2;
     if (*(dirend+2) == '.' && !*(dirend+3)) dirend += 3;