There are several differences in behavior between Interix and traditional systems, such as Solaris, that you might encounter when debugging your ported code. This topic describes some of those differences.
Some users porting code notice that their application memory faults more frequently than it did on the original platform. This usually indicates a defect in the code, not in the Interix subsystem. (A subsystem segmentation fault is a different issue.) A common reason for this to occur is that you are trying to dereference an uninitialized pointer. An uninitialized pointer contains some random bit pattern. An attempt to read or write at the memory address indicated by that bit pattern will succeed or fail, depending on whether the user is allowed access to that address. If it fails, it does so with a segmentation fault. Even if it succeeds, it can cause problems for other applications that are using that portion of memory.
On Windows, most of the four-gigabyte address space is unavailable to the user program. Any attempt to read or write in that space causes an application segmentation fault.
For instance, the code in the following example is incorrect and will behave unexpectedly on a traditional system. It will result in a segmentation fault on an Interix system:
#include <stdio.h>
struct demo
{
int one;
int two;
};
main()
{
struct demo *t1;
t1->one = 7;
printf ("%d\n", t1->one);
}
There are two problems illustrated in this code. First,
demo
is defined, but no actual structure is declared.
Second, the variable t1
is not initialized. The
attempt to dereference t1
, assigning the member one to
the value 7, actually points to some random memory location offset
to give the access to the structure member. The two solutions in
the following example correct the problem:
#include <stdio.h>
struct demo
{
int one;
int two;
} demo2;
main()
{
struct demo *t1;
t1=&demo2;
t1->one = 7;
printf ("%d\n", t1->one);
}
A structure (demo2
) is now declared, and
t1
is initialized to its address.