libc

问题 I'm trying to understand the glibc implementation of fseek . To do so, I downloaded the glibc source code and tried to understand its function execution order. I found the fseek implementation in libio/fseek.c . Basically, it calls the function (or rather the macro) _IO_fseek() using the same parameters. This macro is implemented in libio/iolibio.h . It is defined as _IO_seekoff_unlocked (__fp, __offset, __whence, _IOS_INPUT|_IOS_OUTPUT) (implemented in libio/ioseekoff.c ). The next step in

问题 Let's have a look at this Hello World program #include <stdio.h> int main(int argc, char ** argv) { printf("Hello, World!"); const char* sFile = "/dev/stdout"; // or /proc/self/fd/0 const char* sMode = "w"; FILE * output = fopen(sFile, sMode); //fflush(stdout) /* forces `correct` order */ putc('!', output); // Use output or stdout from stdio.h return 0; } When compiled using the output file descriptor the output is: !Hello, World! when compiled using the stdout file descriptor provided by

问题 I'm trying to find out how to remap memory-mapped files on a Mac (when I want to expand the available space). I see our friends in the Linux world have mremap but I can find no such function in the headers on my Mac. /Developer/SDKs/MacOSX10.6.sdk/usr/include/sys/mman.h has the following: mmap mprotect msync munlock munmap but no mremap man mremap confirms my fears. I'm currently having to munmap and mmmap if I want to resize the size of the mapped file, which involves invalidating all the

问题 I've been using mktime/localtime for time management, including some heavy arithmetic on dates/times. I noticed something very weird when providing to mktime a struct tm that contains negative values. Take the code below. There was a DST change in LA on Nov 3rd, 2013. If I specify time in tm as 2013-11-04 midnight and subtract 24 hours, I get the same value as 2013-11-03 midnight. It is 25 hours difference UTC-wise, which is fine, as with isdst=-1 one could say we're looking at 'wallclock

问题 I am creating a 2D game on Android using OpenGL. Currently I am testing and debugging the game on several devices. The problem I am facing, is the terrible "signal 11" error. When I am playing on my Samsung Galaxy Nexus, everything runs smooth, and I can play it for hours without the game throwing any errors. My Nexus is running Android 4.0 Ice Cream Sandwich. Now, when I run it on other devices, I am getting this signal 11 error. This are the devices which throw the error: HTC Desire HD

问题 It seems that all my adult life I've been tormented by the VC++ linker complaining or balking because various libraries do not agree on which version of the Runtime library to use. I'm never in the mood to master that dismal subject. So I just try to mess with it until it works. The error messages are never useful. Neither is the Microsoft documentation on the subject - not to me at least. Sometimes it does not find functions - because the name-mangling is not what was expected? Sometimes it

问题 I'm writing a return to libc attack for my systems security class. First, the vulnerable code: //vuln.c #include <stdio.h> #include <stdlib.h> int loadconfig(void){ char buf[1024]; sprintf(buf, "%s/.config", getenv("HOME")); return 0; } int main(int argc, char **argv){ loadconfig(); return 0; } I want to use a return to libc attack. Compiling and debugging the program: $ gcc -g -fno-stack-protector -o vuln vuln.c $ gdb vuln (gdb) break loadconfig (gdb) run Reached breakpoint blah blah blah.

问题 I'm writing a return to libc attack for my systems security class. First, the vulnerable code: //vuln.c #include <stdio.h> #include <stdlib.h> int loadconfig(void){ char buf[1024]; sprintf(buf, "%s/.config", getenv("HOME")); return 0; } int main(int argc, char **argv){ loadconfig(); return 0; } I want to use a return to libc attack. Compiling and debugging the program: $ gcc -g -fno-stack-protector -o vuln vuln.c $ gdb vuln (gdb) break loadconfig (gdb) run Reached breakpoint blah blah blah.

问题 The gets function was first deprecated in C99 and finally removed in C11. Yet there is no direct replacement for it in the C library. fgets() is not a drop-in replacement because it does not strip the final '\n' , which may be absent at the end of file. Many programmers get it wrong too. There is a one-liner to remove the linefeed: buf[strcspn(buf, "\n")] = '\0'; , but it is non-trivial and often calls for an explanation. It may be inefficient as well. This is counter-productive. Many

问题 I am trying to catch error messages that libc generates when it detects error conditions. For example, my test code: #include <stdlib.h> int main() { char* p = (char*)malloc(10); free(p); free(p); } Generates this output $ ./main *** Error in `./main': double free or corruption (fasttop): 0x000000000124b010 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7d1fd)[0x7f8c121291fd] ./main[0x400b86] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f8c120cdaf5] ./main[0x400a79] ... <snip> However,