Do you mean 'will the compiler complain' - no. 'Is it a good idea' - Again, probably not.
Reentrant functions should have all of their data passed to them as arguments, and not use global data structures. Semaphores are traffic cops for access to global objects or shared objects.
This sounds like a threads design problem. What are you trying to do?
Consider calling stat() to get the filesize first. Open the file, then move the file pointer forward to some arbitrary place.
If you assume no last line is ever longer than say, 200 characters, then fseek() to within 200 character size units of the end of the file. fread in the last bit of the file into a buffer.
Now you can apply what Narue indicated - you have a container that you can "backwards read" from to get the last line of the file. If you need the last 10 lines, then adjust the file pointer positioning scheme.
If you want to see a generalized algorithm for this, consult the coreutils source for the "tail" utility at www.gnu.org
Code caving creates a supplanting vector to user-controlled data sets, and is usually a game hacking technique, it's also used in exploits.
Therefore, it's usually an asm code block. More than that is totally game-specific and platform-specific information that you'd only get at gaming cheat sites that had forums dedicated to a specific game/platform.
I'd search for the game of interest and platform and the word 'hack' or 'cheat'.
If it not a game thing read: Shellcoder's Handbook by Jack Koziol considered to be basic source for what you're discussing. ie. commandeering a process's data set to control it.
Choices 1. install GNU date (the linux version) so you can use the --date option. Also check the man page for your current version of date - it may be a GNU variant.
2. use C's strptime() function and strftime() function in a small C program
3. install the DATE module for perl, use str2time and format the date
Just to clarify: 1. You can link an entire module statically. 2. You can link just one or two libraries statically, and link the rest of the image dynamically:
cc myfile.c /path/to/mylib.a /path/to/anotherlib.a -o myfile
The "moving over" part is the reason for which static linking exists.
Your problem could be looked at another way: as an implementation/deployment issue. Matching up correct code with correct run-times. If you are working for a company ask them to look at TeamTrack and ChangeMan from Serena. You can also package everything as one tarball and use cvs or whatever to manage your tarballs.
You're on the right track. I don't use Solaris, but I do know it has some (what I think are) funny conventions.
Now that I know it's Solaris, you can use versioning of your .so files, as long as you keep all the old ones out there. You can park all you stuff in a special area that won't get clobbered in an update, then define LD_LIBRARY_PATH (or SHRLIB_PATH) so that dld can open the libraries -if you plan to move them around later. Link specifically against a version like "-l mylib.3.2"
Yes. - it's called a static link. It means that all of the runtime you need is part of the image file - obviously a much bigger image file.
I can't tell which version of unix you have, but your man ld page will tell you how to do that. In most flavors of Unix you provide the cc command with a list of static libraries ".a" files including libc.a. You will also have to put your own runtime into one of these archives as well - or link against the objects in it. Again, the ld manpage is your friend.
Whenever you compile C code you should enable warnings. Some compilers will not complain unless you tell them to complain.
What compiler are you using? Is it an ancient version of BORLAND C++ or TURBO C? You really need to use a modern compiler - there are free ones on the internet starting with gcc.
And in general, don't compile straight C with a C++ compiler even though it seems to work.
