topic Re: strcmp different behaviour between HPUX and LINUX in Operating System - HP-UX

strcmp different behaviour between HPUX and LINUX

Fedele Giuseppe — Tue, 27 Jul 2010 14:29:02 GMT

Hi all,

I have experienced that the following code works on HPUX but does not on LINUX.

It seems that on LINUX the strcmp doesn't manage pointers to not allocated veriables.

Which is the reason?

char **x;

if(strcmp(*x, "") == 0 )
{
printf("EQUAL\n");
}else
{
printf("DIFFERENT\n");
}

Re: strcmp different behaviour between HPUX and LINUX

Fedele Giuseppe — Tue, 27 Jul 2010 15:00:20 GMT

I see in strcmp HPUX man page that:

"Null pointer values for s1 and s2 are treated the same as pointers to empty strings."

and this should explain why it works on HPUX.

Now my doubt is about linux behaviuor: is it a different implementation of the routine in this operating system?

Thanks

Giuseppe

Re: strcmp different behaviour between HPUX and LINUX

David Johns — Tue, 27 Jul 2010 16:30:15 GMT

Yes it is a different implementation on Linux. It does conform to the standards: SVr4, 4.3BSD, C89, C99.

Did you remember to include string.h and allocate and initialize x?

-Dave

Re: strcmp different behaviour between HPUX and LINUX

Fedele Giuseppe — Tue, 27 Jul 2010 16:45:06 GMT

Hi

from HPUX man pages I see that strcmp does conform to ANSI C standard:

STANDARDS CONFORMANCE
strcmp(): AES, SVID2, SVID3, XPG2, XPG3, XPG4, FIPS 151-2, POSIX.1, ANSI C

whereas from LINUX man pages I see:

CONFORMING TO
SVr4, 4.3BSD, C89, C99.

Does it means that the linux implementation does not conform ANSI C?

Thanks

Giuseppe

Re: strcmp different behaviour between HPUX and LINUX

David Johns — Tue, 27 Jul 2010 17:41:38 GMT

Hi Fedele:

C89 and C99 are the 1989 and 1999 ANSI C standards.

> It seems that on LINUX the strcmp doesn't manage pointers to not allocated veriables.

Please see the following:

#include
#include
#include

int
main(int argc, char *argv[])
{
char **x;

printf("%p\n", (void *) x);
printf("%p\n", (void *) *x);
printf("%d\n", **x);
return EXIT_SUCCESS;
}

%./a.out
0x773600
0x57e58955
Segmentation fault

Re: strcmp different behaviour between HPUX and LINUX

Matti_Kurkela — Tue, 27 Jul 2010 21:13:01 GMT

You're dereferencing an uninitialized pointer. The C programming language does not guarantee that this will work.

> is it a different implementation of the routine in this operating system?

Yes, the implementation is different.
HP-UX contains HP's own C library, while Linux uses open-source GNU glibc.

By ANSI C, the strcmp(3) function is not required to accept NULL parameters. This may be a feature of some standards that HP-UX complies with but Linux does not. Or it might be a HP-UX specific feature.

You're also making three dangerous assumptions:

1.) that the uninitialized memory location assigned to store **x contains by default a bit pattern that is equivalent to a NULL pointer.

This depends on the hardware architecture and OS implementation, and is not generally guaranteed.

2.) that you can dereference a NULL pointer, i.e. you can read *(NULL).

Whenever possible, Linux guarantees that this *is not* true.

I understand that in modern Linux, the NULL address is usually "booby-trapped", so that any attempt to dereference it is guaranteed to cause the program to crash immediately with a segmentation fault. As a result, the platform will force you to break bad habits and to write portable code.

3.) that there is a NULL value at the end of the NULL pointer:

( (void *) *(NULL) ) == NULL

The original ANSI C standard does not define this; the result of dereferencing a NULL pointer will be platform-specific undefined behaviour. Any program that assumes it can successfully dereference a NULL pointer will not be _portable_ ANSI C.

In program code:

char **x;

x = NULL;

printf("If this program crashes now, assumption 2 is incorrect because *x is not accessible\n");
if ( *x == NULL ) {
printf("Assumptions 2 and 3 are correct, at least this time.\n");
} else {
printf("Assumption 2 is correct but assumption 3 is incorrect: *x is accessible but is not NULL\n");
}

By what I understand, these assumptions used to be valid in HP-UX (older PA-RISC versions at least). This allows some pointer algorithms to be written in more compact form, with less explicit tests for NULL.

But later this has been found to encourage sloppy thinking and sloppy coding. It also causes pain when code must be ported from an architecture that allows dereferencing NULL to an architecture that doesn't.

(For example, in the old Commodore 64, the memory addresses 0x0000 and 0x0001 contained important hardware control registers. Because there was no MMU and no way to create a virtual address space for user-space process, setting *(NULL) to NULL would have, among other things, disabled all system ROMs and started the cassette tape drive motor.)

MK

Re: strcmp different behaviour between HPUX and LINUX

Matti_Kurkela — Tue, 27 Jul 2010 21:26:12 GMT

On my Linux/x86_64, the result of David's program is:

$ ./a.out
(nil)
Segmentation fault

In other words, Linux can be more strict than HP-UX used to be.

I also have understood that HP-UX/Itanium is by default a stricter platform for C programmers than HP-UX/PA-RISC. I think there are some compiler options that can minimize the differences, but some of the old PA-RISC sloppiness absolutely must be fixed when porting the code to Itanium. See the porting guides provided by HP for details.

MK

Re: strcmp different behaviour between HPUX and LINUX

Dennis Handly — Tue, 27 Jul 2010 22:33:39 GMT

There are two reasons why this works on HP-UX.
1) The default is -Z, which allows NULL pointer dereferences. Use -z to abort.
2) strcmp has been extended to check for NULL pointers.

None of these lead to good programming practices or portable code. :-(

>this should explain why it works on HPUX.

Exactly.

>Now my question is about Linux behavior

Linux is stricter here.

>Does it means that the Linux implementation does not conform ANSI C?

This is a quality of implementation issue, and has nothing to do with the Standard. The program is illegal.

>MK: 1) that the uninitialized memory location assigned to store **x contains by default a bit pattern that is equivalent to a NULL pointer.

For a global, this is practically guaranteed. Especially for C++.

>But later this has been found to encourage sloppy thinking and sloppy coding.

Right.

>I also have understood that HP-UX/Integrity is by default a stricter platform for C programmers than HP-UX/PA-RISC.

Only because the aC++ compiler is newer.

Re: strcmp different behaviour between HPUX and LINUX

Fedele Giuseppe — Wed, 28 Jul 2010 06:40:20 GMT

Hi all,

I think that we can summarize the answer to my question by saying that:

1. both HPUX and Linux strcmp implementations complie with ANSI C standard.

2. HPUX implementation adds some specific features, like the NULL pointers managemet.

Many thanks

Giuseppe

Re: strcmp different behaviour between HPUX and LINUX

Fedele Giuseppe — Wed, 28 Jul 2010 06:41:57 GMT

Re: strcmp different behaviour between HPUX and LINUX

Steven Schweda — Wed, 28 Jul 2010 09:55:25 GMT

And:

3. Code which relies on dereferencing NULL
pointers (or on any uninitialized values) is
asking for trouble.