[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OpenVMS and CVS-1_11_21 client

From: Piet Schuermans
Subject: Re: OpenVMS and CVS-1_11_21 client
Date: Mon, 14 Nov 2005 23:48:46 +0100


It works fine. Just rebuild and tested.

I had some problem with [.src]client.c
Based on your last e-mail I restored client.c to it's original state, meaning I removed my error handling in
both handle_m and handle_e.  Result check-out CVS test failed.
Error: "cvs: cannot write to stderr: socket operation on non-socket"
So I restored the error handling in both routines and CVS Client tests returned no errors.

[ [part of e-mail addressing select(..) problem in handle_m and handle_e] The problem is not the client.c code but an VMS issue with file descriptors stderr and stdout that are not associated with a socket. (VMS Release notes => The select() function has been corrected to return failure status if either invalid file descriptor or file descriptor not associated with a socket is found in one of the specified file descriptor sets. In case of invalid file descriptor, the select() function sets errno to EBADF. In case of a file descriptor not associated with a socket, the function sets errno to ENOTSOCK. Failure with errno set to EBADF is the standard requirement for the select() function. Failure with errno set to ENOTSOCK is because currently the select() function can operate only on sockets. So if I check in both routines not only the returning value of select (...) but also the errno. And handle the case when errno == ENOTSOCK. it would work again with the "original" cvs source files. So instead of simple comment out the select() function I replacing it with a vms specific wrap function VMS_Select( ) in which I handle the set errno values.
] ]


On Nov 14, 2005, at 20:49, Mark D. Baushke wrote:

Hi Piet,

I am given to understand by a MacOS X (10.3.6)
user that neither the MACOS nor the TARGET_OS_MAC
macros are being defined during a normal cvs
configure and build operation which makes the
VMS_filename_classes symbol become unresolved due
to the last patch to system.h

It appears that USE_VMS_FILENAMES may be a
reasonable macro to use as an alternative to
choose between VMS and MacOS X filesysstems.

Could you verify that this patch would work for

        Thank you,
        -- Mark

Index: system.h
RCS file: /cvsroot/cvs/ccvs/lib/system.h,v
retrieving revision 1.81
diff -u -p -u -p -r1.81 system.h
--- system.h    9 Nov 2005 10:59:21 -0000       1.81
+++ system.h    14 Nov 2005 19:47:22 -0000
@@ -284,12 +284,12 @@ extern unsigned char WNT_filename_classe
* WOE32 needs its own class since \ and C:\ style absolute paths also need
    * to be accounted for.
-#  if defined(MACOS) || defined(TARGET_OS_MAC)
-# define FOLD_FN_CHAR(c) (OSX_filename_classes[(unsigned char) (c)])
-extern unsigned char OSX_filename_classes[];
-#  else
+#  if defined(USE_VMS_FILENAMES)
# define FOLD_FN_CHAR(c) (VMS_filename_classes[(unsigned char) (c)])
 extern unsigned char VMS_filename_classes[];
+#  else
+# define FOLD_FN_CHAR(c) (OSX_filename_classes[(unsigned char) (c)])
+extern unsigned char OSX_filename_classes[];
 #  endif
 # endif /* __CYGWIN32__ || WOE32 */

reply via email to

[Prev in Thread] Current Thread [Next in Thread]