11.23 IA doesnt dump core during copy into NULL pointer

[siba]

the below prog dumps SIGBUS core on v11.11 PA-RISC(32-bit) machine while works fine on V11.23 Itanium(64-bit) with same compiler options.
CC Compiler details:
PA-RISC:
$Revision: 92453-07 linker linker crt0.o B.11.16.01 030316 $
LINT B.11.11.29484.GP CXREF B.11.11.29484.GP
HP92453-01 B.11.11.29484.GP HP C
ITANIUM:
HP aC++/ANSI C B3910B A.05.50 [May 15 2003]
Any clues on what causes the difference
---
char *pszTemp = NULL;
strcpy(pszTemp, "copy into NULL pinter");
---

[Ramesh S]

Hi

As far as i know, Application compiled for 64bit will not work on 32bit system. You may need to recompile that

Application compiled for 32 bit may work on 64bit OS, but again in order to get optimization, need to recompile for 64bit.

Thank You, Have a Good Day!!!

Best Regards,
Ramesh S

[Don Morris_1]

Looks to me like strcpy() in the current IPF implementation is just not stupid enough to write to NULL. Consider:

# cat stupid.c
#include
#include
#include
#include

int
main(int argc, char *argv[])
{
char *pszTemp = NULL;

printf("pszTemp: 0x%lp\n", pszTemp);

strcpy(pszTemp, "copy into NULL pointer");

printf("Copied\n");

pszTemp[0] = 'c';
pszTemp[1] = '\0';

printf("Out\n");
exit(EXIT_SUCCESS);
}

# cc +DD64 -o stupid stupid.c
# ./stupid
pszTemp: 0x0000000000000000
Copied
Memory fault(coredump)

If/when I remove the direct write to NULL, the program runs to completion.

So it isn't a matter of the binary or platform layout -- it is the copy itself. memcpy() does not have the same behavior:
# cat stupid.c
#include
#include
#include
#include

char *copy_const_string = "copy into NULL pointer";

int
main(int argc, char *argv[])
{
char *pszTemp = NULL;

printf("pszTemp: 0x%lp\n", pszTemp);

strcpy(pszTemp, copy_const_string);

printf("Copied\n");

memcpy(pszTemp, copy_const_string, 2);

printf("Out\n");
exit(EXIT_SUCCESS);
}
# cc +DD64 -o stupid stupid.c
# ./stupid
pszTemp: 0x0000000000000000
Copied
Memory fault(coredump)

And the final word -- from string(3C) [which is where strcpy() lives]:
WARNINGS
The functions strcat(), strncat(), strcpy(), strncpy(), strtok(), and
strtok_r() alter the contents of the array to which s1 points. They
do not check for overflow of the array.

Null pointers for destination strings cause undefined behavior.

(there's more -- but that's the key line).

Undefined behavior means just this -- the behavior is not defined and can be different on different runs, binaries, platforms, etc. Calling strcpy() with NULL as a destination string is just not something you should do. If you want to catch such things in your code - I'd wrap strcpy() in a function or macro and use assert(dest_string != NULL); before the call.

[siba]

what i meant was the source code was compiled in both platforms with identical options.
CC compiler versions for both is mentioned in my previous post.

... else it wouldnt execute :)

[siba]

thanks Don,

It was kind of closer to what i need.

and i agree to what you mentioned, but we do have a legacy code which uses strcpy/strcat heavily and changing everything may not be feasible....

i needed it to dump core on IA simular to the PA-RISC systems so that i can capture the same is sighandler and terminate the process...

Guess am shootin in the dark but is there any compiler option that can help me resolve the issue?

[Hein van den Heuvel]

>> i needed it to dump core on IA simular to the PA-RISC systems so that i can capture the same is sighandler and terminate the process...

I see the words, but I'm having a hard time making sense out of them.

A program which provides a NULL pointer as target for strcpy is broken. What is the point in setting up a mechanism to capture the failure? Fix it! The program _could_ test the result for strcpy.

How about writting your own strcpy? It is not rocket science to get the functionality in place either as a macro, or as a function. To get it optimal is more work.

Hwo about writing a jacket routine with the same name. On first activation have is use dlopen/dlsym to find an address for the read strcpy. Next try to write a byte into the destination pointer. If that works, call the real strcpy through its dyna,icly obtained address (strcpy_pointer). If it fails, then you'll have your signal.

Hope this helps some,
Hein.

[Dennis Handly]

>i needed it to dump core on IA similar to the PA-RISC systems so that i can capture the same is sighandler and terminate the process.

You are out of luck. You must add an explicit check or Hein's explicit wrapper.

>Guess am shooting in the dark but is there any compiler option that can help me resolve the issue?

Of course not. While ld's -z will prevent loads from null pointers this is the first I've heard that IPF's strcpy checks BOTH source and target for NULL.