bug-gnu-utils
[Top][All Lists]
Advanced

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

GAWK 3.1.1 Possible Bug: Windows versus Unix


From: Jim Sievers
Subject: GAWK 3.1.1 Possible Bug: Windows versus Unix
Date: Fri, 9 Aug 2002 15:22:07 -0400

I believe I may have discovered a portability bug within the builtin.c
module which manifests itself on Windows NT implementations
and may also be related to the GCC library implementation of the standard C
library system() command when compiled under
Windows.

I was having trouble porting tested/debugged GAWK code running on Unix to a
Windows 2000/NT environment and discovered a
problem related to the return values of the GAWK SYSTEM() command. I was
having GAWK use the SYSTEM() command to call
a unix command ( test -d baddirectory for example )  which would normally
return zero and non-zero based upon whether the directory
exists. 

The Unix implementation of the GAWK program works correctly and returns both
zero and non-zero return values.
The Windows NT implementation incorrectly returned zero regardless if the
directory exists or not.

Upon further investigation and checking out the latest GAWK 3.1.1 tar ball,
I believe the problem may be a portability bug in the C
code related to compilation on different environments. The do_system()
function within the builtin.c module uses the following statement
directly following the call to the standard C library system() function:

        ret = (ret >> 8) & 0xff;

This will shift the return value from the system() library function, mask it
and return it to the user.
However, this causes a problem for the Windows NT implementation as follows:

Here is a small sample C program which calls the C library system() function
to demonstrate what is happening.
Program was run using GCC implementations on both Unix and Windows NT

# gcc -v     (UNIX)
Reading specs from /usr/local/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.1/specs
Configured with: ../gcc-3.1/configure --disable-nls
Thread model: aix
gcc version 3.1

C:\ecfwin>gcc -v   (WINDOWS)
Reading specs from c:/djgpp/lib/gcc-lib/djgpp/3.1/specs
Configured with: ../configure i586-pc-msdosdjgpp --prefix=/dev/env/DJDIR
--disab
le-nls
Thread model: single
gcc version 3.1

TESTIT.C
#include <stdio.h>
#include <stdlib.h>

int main(argc, argv)
int argc;
char *argv[];
{
        int ret=0;

        ret = system("test -d baddirectory");
        printf("Pre RET=%d\n",ret);
        ret = (ret >> 8) & 0xff;
        printf("Post RET=%d\n",ret);
        ret = 254;
        ret = (ret >> 8) & 0xff;
        printf(" 254 RET=%d\n",ret);
        ret = 255;
        ret = (ret >> 8) & 0xff;
        printf(" 255 RET=%d\n",ret);
        ret = 256;
        ret = (ret >> 8) & 0xff;
        printf(" 256 RET=%d\n",ret);
        ret = 32767;
        ret = (ret >> 8) & 0xff;
        printf(" 32727 RET=%d\n",ret);

        return (int)0;
}

Here are the Windows 2000 results of the test
C:\ecfwin>testit
Pre RET=1
Post RET=0
 254 RET=0
 255 RET=0
 256 RET=1
 32727 RET=127

C:\ecfwin>mkdir baddirectory

C:\ecfwin>testit
Pre RET=0
Post RET=0
 254 RET=0
 255 RET=0
 256 RET=1
 32727 RET=127

Here are the same exact results on the Unix (AIX implementation)

# ./testit
Pre RET=256
Post RET=1
 254 RET=0
 255 RET=0
 256 RET=1
 32727 RET=127
# mkdir baddirectory
# ./testit
Pre RET=0
Post RET=0
 254 RET=0
 255 RET=0
 256 RET=1
 32727 RET=127

As you can see, the Unix implementation will return proper values from the
GAWK SYSTEM() command however, the Windows NT
implementation is not returning proper values. The system() C library
function is meeting the standard on both environments by returning
zero and non-zero return values so I do not believe that it is necessarily a
problem with the GCC C library implementation of system().

The code located in the builtin.c module should not shift the value as any
return value less than 256 will cause the GAWK implemention
to not work correctly. Simply changing the statement to the following should
correct the problem:

        ret = ret & 0xff;

I was having trouble trying to recompile the Windows implementation of GAWK.
Any possibility of checking into this and releasing a
repaired version?

Thanks!
-Jim

James Sievers
Professional Services Engineer
Harbor Technologies
9000H Commerce Parkway
Mt. Laurel, NJ 08054
Email: address@hidden
Office: 856-222-0643 x1067




reply via email to

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