Comment 1 for bug 1951848

I don't have access to any VxWorks 6.x installations earlier than 6.8 and I don't generally run the EPICS tests on that because we don't use it any more here at APS. PSI is the only EPICS site that I know of which is actively working with VxWorks < 6.9 now.

Re epicsStdioTest: You may be able to get this test to pass if you use ftp to boot and your ftp server has access to a writable directory. I have an 'incoming' directory which is world-writable and I can cd to "server:/path/to/incoming" before running the test to get that it to pass.

Re macDefExpandTest: Thanks for that explanation, that makes sense (I was seeing these failures too). I can modify macCore.c's lookup() routine to check for a NULL or empty name before it calls getenv() and return NULL in that case — that's a 1-line change:

--- a/modules/libcom/src/macLib/macCore.c
+++ b/modules/libcom/src/macLib/macCore.c
@@ -588,7 +588,7 @@ static MAC_ENTRY *lookup( MAC_HANDLE *handle, const char *name, int special )
     }
     if ( (special == FALSE) && (entry == NULL) &&
          (handle->flags & FLAG_USE_ENVIRONMENT) ) {
- char *value = getenv(name);
+ char *value = name && *name ? getenv(name) : NULL;
         if (value) {
             entry = create( handle, name, FALSE );
             if ( entry ) {

It looks like we shouldn't be passing either into getenv() anyway, so this is a legitimate change for the other targets too. I just committed that change along with my fix to add redirect support for vprintf() to epicsStdio.h which fixed those failures.