ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
But same code crash under linux (Red Hat). It’s crashing with obvious reasons.
Best solution will be put the check before each strcpy and throw the error in case of 2nd arg pointing to NULL.
Currently we are doing the HP-UX to Linux migration, and it will be very hard to do these changes in all the places.
When your code will gift you the "segmentation fault" ,the debugger will lead your way and point you to the buggy code. That way you'll spend less time hunting for bugs in the large code.
Yes Code is broken agreed. But it's a fact it's working fine under HP-UX. May be because of smart compiler of HP-UX.
I agree, code is not written good. And this problem will not be only with strcpy, it’s going to be with all string operation.
HP-UX given the flexibility to do this mistake, and guys are doing it since last 10-15 years without any problem.
Now we are migrating to the Linux (just because of cost cutting).
Fix for this problem is very easy, but it’s 20-30 thousand files, I don’t remember how many string operations are there.
Fix one by one all the string operation will take years, so looking for some other smart solution like re-writing the string function again to handle NULL pointer.
Yes, you are right. But it's actually not ignoring.
It's just putting a[0] = '\0';
which is exactly our implemetation is looking for.
I think because of this no one notice this problem even exist.
Now only because of Linux we started to get this problem.
Code is nearly about 10-15 year old.
Hi @amarg, I'm here in 2023 with same issue. Porting legacy C code from HP-UX to RHEL and foudn that, HP-UX complier can derefrence NULL pointer inside string operation methods like strcpy, strlen. However, RHEL GCC complier SegFaluts.
What solution applied you back then to resolve this issue with derefrencing NULL pointer for RHEL GCC complier.
Any wrapper method for legacy strcpy()? Thanks for your suggestions.
Aix is another example for a platform, where address zero is readable (the kernel starts at address zero).
There is no universal solution, the bugs have to be found one by one. The good news is that you can use valgrind on Linux: it will find many other problems as well (e.g. uninitalized variables).
PS: if your old platform is big endian, then expect some problems on little endian platform x86 (or amd64).
PPS: Current gcc/clang compilers give you many useful warnings, I suggest you fix them all.
Any wrapper method for legacy strcpy()? Thanks for your suggestions.
There is no wrapper. It is just incorrect (strcpy to/from NULL).
That code is just broken and useless (not strcpy, but where is it called from). So you need to inspect that one by one (line by line) and find out what was the original intention.
There is only one general way to avoid segfault:
define (overwrite) strcpy to check first a and b and do nothing if any of them is NULL. But I don't think your code will work that way.
Yes, you are right. But it's actually not ignoring.
It's just putting a[0] = '\0';
which is exactly our implemetation is looking for.
If you need the process of finding these errors to go faster, use clang-tidy:
Code:
❯ cat init.c
#include <stdio.h>
#include <string.h>
int main()
{
char a[10];
char *b = NULL;
strcpy(a, b);
printf("%s\n", a);
}
~/Documents/init via C v13.1.1-gcc
❯ bear -- gcc init.c
~/Documents/init via C v13.1.1-gcc
❯ clang-tidy init.c
2 warnings generated.
init.c:10:5: warning: Null pointer passed to 2nd parameter expecting 'nonnull' [clang-analyzer-core.NonNullParamChecker]
strcpy(a, b);
^ ~
init.c:8:5: note: 'b' initialized to a null pointer value
char *b = NULL;
^~~~~~~
init.c:10:5: note: Null pointer passed to 2nd parameter expecting 'nonnull'
strcpy(a, b);
^ ~
init.c:10:5: warning: Call to function 'strcpy' is insecure as it does not provide bounding of the memory buffer. Replace unbounded copy functions with analogous functions that support length arguments such as 'strlcpy'. CWE-119 [clang-analyzer-security.insecureAPI.strcpy]
strcpy(a, b);
^~~~~~
init.c:10:5: note: Call to function 'strcpy' is insecure as it does not provide bounding of the memory buffer. Replace unbounded copy functions with analogous functions that support length arguments such as 'strlcpy'. CWE-119
strcpy(a, b);
^~~~~~
There are no shortcuts beyond this. If fixing the technical debt in this legacy code is going to take years, then, well, that's your estimate.
sed 's/strcpy(a, b);/strcpy(a, (b == NULL ? "" : b));/'
You might consider looking into more specialized tools than sed. For example, I've seen the Linux kernel project reference https://coccinelle.lip6.fr/
Quote:
Coccinelle is a program matching and transformation engine which provides the language SmPL (Semantic Patch Language) for specifying desired matches and transformations in C code.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.