Thread replies: 11
Thread images: 1
Thread images: 1
Anonymous
Technical question about glibc 2016-10-23 13:14:03 Post No. 57202778
[Report] Image search: [Google]
Technical question about glibc 2016-10-23 13:14:03 Post No. 57202778
[Report] Image search: [Google]
File: shapeimage_1-1.png?resize=228%2C225.png (16KB, 228x225px) Image search:
[Google]
16KB, 228x225px
why the output of#include <stdio.h>
int main()
{
printf("%s", NULL);
return 0;
}
is(null)%
but the output of#include <stdio.h>
int main()
{
printf("%s\n", NULL);
return 0;
}
is a segfault ?
>>
>>57202778
Why don't you check the source, you lazy assed faggot.
>>
>>57203091
>check the warning, you lazy assed faggot.
>>
>>57202778
Both are undefined behavior.
The actual reason though is that the latter is optimized to puts() which does just crash on null whereas the former uses printf and glibc decided to print out (null) (which it didn't need to)
>>
>>57202778
Because you touch yourself at night
>>
>>57203091
>>57203302
>>57203377
Kill yourself you fucking cancer
>>
>>57202778
My guess would be printf handles a straight up null pointer by doing nothing, so no memory is accessed and thus no segfault.
In the second case you'd get a char[] containing null and a line break character. But the actual array pointer wouldn't be null so printf would try to print the string. So then you'll try to access a null pointer and segfault?
>>
>>57203401
No you, fucking nigger jew cancerous bastard fuckwit mongoloid child prick
>>
>>57202778
Hello, this is the actual answer :
gcc replace call to printf with the "%s\n" format string by a call to the puts function.
printf default implementation check null pointers, puts doesnt.
You're welcome.
>>
>>57204260
with clang you don't get a segfault
>>
>>57204479
because clang doesnt has this behavior and will call printf instead of puts.
Thread posts: 11
Thread images: 1
Thread images: 1