I have just noticed about a library SFIO for a safe and fast IO processing in C. But it is not very up to date. The last version of library is released in 2005 2012 and I couldn't assess that if the claimed benefits of SFIO over STDIO are still valid with comparison to the recent releases of standard IO library. Also Would it be reasonable to use this library in a production code?
I would prefer using standard stuffs instead of relying on a lib that is not maintained or developed anymore. Do tests however to know if your code really benefits from its usage. If it is not hard, develop your code with switches definible at compile time to use sfio or the standard approach, so that you can switch to one or another according to needs and if you notice sfio is giving problems.
I am only aware of this fact this SFIO library claims to be more efficient, safe, and robust, yet I never bothered to try this library, as standard io library is always fine with me.
I want to ask what benefits they claim which you are not able to assess. can you give details and also the exact references.
Also I would really want to ask you why do you want to rely on some non standard library over standard one, what is your special purpose.
Anyways if there is no such special requirement I would suggest you to use only standard library.
Also as you have asked about using it in a production code, so my suggestion is a absolutely NO.
Thanks
Alok.Kr.
Related
I'm working on some code for a university assignment, where we were asked to use API available in c++ standard for our thread management. It was also implied that if there exists standardized C API we are free to use that. Sadly, as far as I researched, there is no cross platform sync API for C and all the examples i saw used either UNIX or windows API.
Hopefully someone who had more experience with C can tell me a cross platform thread sync API is a part of any C standart.
Well, there's the Concurrency support library introduced in C11, but it's optional.
I can't think of a good reason to use that instead of C++, whose concurrency library is not optional and which gives you RAII helpers like std::unique_lock, unless you really have to.
This is probably a good time to invest in an up-to-date book, or practice using reference materials and searching - I've never used this library, and it took me seconds to find.
I was looking at the NtDll export table on my Windows 10 computer, and I found that it exports standard C runtime functions, like memcpy, sprintf, strlen, etc.
Does that mean that I can call them dynamically at runtime through LoadLibrary and GetProcAddress? Is this guaranteed to be the case for every Windows version?
If so, it is possible to drop the C runtime library altogether (by just using the CRT functions from NtDll), therefore making my program smaller?
There is absolutely no reason to call these undocumented functions exported by NtDll. Windows exports all of the essential C runtime functions as documented wrappers from the standard system libraries, namely Kernel32. If you absolutely cannot link to the C Runtime Library*, then you should be calling these functions. For memory, you have the basic HeapAlloc and HeapFree (or perhaps VirtualAlloc and VirtualFree), ZeroMemory, FillMemory, MoveMemory, CopyMemory, etc. For string manipulation, the important CRT functions are all there, prefixed with an l: lstrlen, lstrcat, lstrcpy, lstrcmp, etc. The odd man out is wsprintf (and its brother wvsprintf), which not only has a different prefix but also doesn't support floating-point values (Windows itself had no floating-point code in the early days when these functions were first exported and documented.) There are a variety of other helper functions, too, that replicate functionality in the CRT, like IsCharLower, CharLower, CharLowerBuff, etc.
Here is an old knowledge base article that documents some of the Win32 Equivalents for C Run-Time Functions. There are likely other relevant Win32 functions that you would probably need if you were re-implementing the functionality of the CRT, but these are the direct, drop-in replacements.
Some of these are absolutely required by the infrastructure of the operating system, and would be called internally by any CRT implementation. This category includes things like HeapAlloc and HeapFree, which are the responsibility of the operating system. A runtime library only wraps those, providing a nice standard-C interface and some other niceties on top of the nitty-gritty OS-level details. Others, like the string manipulation functions, are just exported wrappers around an internal Windows version of the CRT (except that it's a really old version of the CRT, fixed back at some time in history, save for possibly major security holes that have gotten patched over the years). Still others are almost completely superfluous, or seem so, like ZeroMemory and MoveMemory, but are actually exported so that they can be used from environments where there is no C Runtime Library, like classic Visual Basic (VB 6).
It is also interesting to point out that many of the "simple" C Runtime Library functions are implemented by Microsoft's (and other vendors') compiler as intrinsic functions, with special handling. This means that they can be highly optimized. Basically, the relevant object code is emitted inline, directly in your application's binary, avoiding the need for a potentially expensive function call. Allowing the compiler to generate inlined code for something like strlen, that gets called all the time, will almost undoubtedly lead to better performance than having to pay the cost of a function call to one of the exported Windows APIs. There is no way for the compiler to "inline" lstrlen; it gets called just like any other function. This gets you back to the classic tradeoff between speed and size. Sometimes a smaller binary is faster, but sometimes it's not. Not having to link the CRT will produce a smaller binary, since it uses function calls rather than inline implementations, but probably won't produce faster code in the general case.
* However, you really should be linking to the C Runtime Library bundled with your compiler, for a variety of reasons, not the least of which is security updates that can be distributed to all versions of the operating system via updated versions of the runtime libraries. You have to have a really good reason not to use the CRT, such as if you are trying to build the world's smallest executable. And not having these functions available will only be the first of your hurdles. The CRT handles a lot of stuff for you that you don't normally even have to think about, like getting the process up and running, setting up a standard C or C++ environment, parsing the command line arguments, running static initializers, implementing constructors and destructors (if you're writing C++), supporting structured exception handling (SEH, which is used for C++ exceptions, too) and so on. I have gotten a simple C app to compile without a dependency on the CRT, but it took quite a bit of fiddling, and I certainly wouldn't recommend it for anything remotely serious. Matthew Wilson wrote an article a long time ago about Avoiding the Visual C++ Runtime Library. It is largely out of date, because it focuses on the Visual C++ 6 development environment, but a lot of the big picture stuff is still relevant. Matt Pietrek wrote an article about this in the Microsoft Journal a long while ago, too. The title was "Under the Hood: Reduce EXE and DLL Size with LIBCTINY.LIB". A copy can still be found on MSDN and, in case that becomes inaccessible during one of Microsoft's reorganizations, on the Wayback Machine. (Hat tip to IInspectable and Gertjan Brouwer for digging up the links!)
If your concern is just the need to distribute the C Runtime Library DLL(s) alongside your application, you can consider statically linking to the CRT. This embeds the code into your executable, and eliminates the requirement for the separate DLLs. Again, this bloats your executable, but does make it simpler to deploy without the need for an installer or even a ZIP file. The big caveat of this, naturally, is that you cannot benefit to incremental security updates to the CRT DLLs; you have to recompile and redistribute the application to get those fixes. For toy apps with no other dependencies, I often choose to statically link; otherwise, dynamically linking is still the recommended scenario.
There are some C runtime functions in NtDll. According to Windows Internals these are limited to string manipulation functions. There are other equivalents such as using HeapAlloc instead of malloc, so you may get away with it depending on your requirements.
Although these functions are acknowledged by Microsoft publications and have been used for many years by the kernel programmers, they are not part of the official Windows API and you should not use of them for anything other than toy or demo programs as their presence and function may change.
You may want to read a discussion of the option for doing this for the Rust language here.
Does that mean that I can call them dynamically at runtime through
LoadLibrary and GetProcAddress?
yes. even more - why not use ntdll.lib (or ntdllp.lib) for static binding to ntdll ? and after this you can direct call this functions without any GetProcAddress
Is this guaranteed to be the case for every Windows version?
from nt4 to win10 exist many C runtime functions in ntdll, but it set is different. usual it grow from version to version. but some of then less functional compare msvcrt.dll . say for example printf from ntdll not support floating point format, but in general functional is same
it is possible to drop the C runtime library altogether (by just using
the CRT functions from NtDll), therefore making my program smaller?
yes, this is 100% possible.
gcc (GCC) 4.7.2
PJ SIP 2.1
Hello,
I am developing an application that will use the PJSIP API.
Just looking at the API documentation and I see some functions that seem to be just wrappers for the standard C library. i.e. pj_memset, pj_strncpy, pj_strlen, etc.
I can see some alternatives that might be worth considering pj_strncpy_with_null() which will always NULL terminate a string. A another advantage could be is that the pjsip uses a pj_str_t structure to store the string and the size. Which could be better than using a normal C string.
And is there any point using pj_size_t over size_t which is portable anyway?
The link for quick reference is here:
http://www.pjsip.org/pjlib/docs/html/group__PJ__PSTR.htm
It there any real advantage using PJSIP over the standard C library?
Many thanks for any suggestions,
Short answer: Use the PJSIP API (all of it).
Long answer: It depends.
If you were programming an application for standard Desktops, that is, x86/x64 Windows/Mac/Linux, then no, it wouldn't really matter too much if you used the standard C library or wrappers like the PJSIP functions. Practically, of course, there might be functions that take (as you pointed out) the pj_str_t struct instead of a char *; it would be easier then to use the PJSIP API just to simplify and remove the need for conversions.
The reason for wrappers, I'm assuming, is to make it easier to develop on embedded devices. I don't mean just ARM or other non-x86 processors—though it could apply there as well; I mean custom embedded devices: things that have a very specific purpose and change infrequently. These embedded devices have very limited capabilities and sometimes even lack an OS. Without an OS, these processors might not have a malloc function or the like. Frequently, the libraries associated with the devices, since they are customized so much, are not entirely "standard" and differ in some small way. By having wrappers for everything, PJSIP can avoid most issues and even provide implementations across the board for things such as strcpy or malloc such that all devices run the "same" code.
Wrappers also provide the means for "hooks." Hooks enable better error messaging (and possibly handling). It's unclear whether PJSIP is doing this (I have never used PJSIP—I am talking from experience using other frameworks), but I am pointing it out just to show why a framework might bother wrapping everything.
In the end, it boils down to your purpose: if you chose to use PJSIP in the first place, then I would go all out and use all of its API. If you are only using it in a few places (for whatever reason) then it probably doesn't matter. Again, it appears that PJSIP is targeting embedded devices (it lists Nokia and even RTOS systems), where it is fairly common to provide wrappers for even "standard" functions. If this is the case, and you are using it in this way, definitely use the entire API.
Will you be sticking with pjsip?
PJSIP source code ("The Software") is licensed under both General
Public License (GPL) version 2 or later and a proprietary license that
can be arranged...
If you think the GPL may be too restrictive for future expansion (such as Android's no-GPL-in-userspace policy) and their proprietary license is not acceptable, you may benefit from using your own portable code/wrappers that you could use with a less restrictive BSD stlye library like Baresip
There are plenty of other methods to provide needed functionality where the standard C library does not support it, many of which will be better tested (I hate to mention autotools, but... it does support most platforms - some would say too many) Or you could include implementations/adaptations from musl-libc
Another thing to consider is the C api is based on standards and fairly set in stone while the wrappers in a given project are much more free to break API compatibility from version to version (just ask a glib/gtk programmer)
I'm looking for a quick guide to basic dll hooking in windows with C, but all the guides I can find are either not C, or not windows.
(The DLL is not part of windows, but a third party program)
I understand the principle, but I don't know how to go about it.
I have pre-existing source code in C++ that shows what I need to hook into, but I don't have any libraries for C, or know how to hook from scratch.
The detours license terms are quite restrictive.
If you merely want to hook certain functions of a DLL it is often cheaper to use a DLL-placement attack on the application whose DLL you want to hook. In order to do this, provide a DLL with the same set of exports and forward those that you don't care about and intercept the rest. Whether that's C or C++ doesn't really matter. This is often technically feasible even with a large number of exports but has its limitations with exported data and if you don't know or can't discern the calling convention used.
If you must use hooking there are numerous ways including to write a launcher and rewrite the prepopulated (by the loader) IAT to point to your code while the main thread of the launched application is still suspended (see the respective CreateProcess flag). Otherwise you are likely going to need at least a little assembly knowledge to get the jumps correct. There are plenty of liberally licensed disassembler engines out there that will allow you to calculate the proper offsets for patching (because you don't want to patch the middle of a multi-byte opcode, for example).
You may want to edit your question again to include what you wrote in the comments (keyword: "DLL hooking").
loading DLLs by LoadLibrary()
This is well known bad practice.
You might want to look up "witch" or "hctiw", the infamous malware dev. there's a reason he's so infamous - he loaded DLLs with LoadLibrary(). try to refrain from bad practice like that.
I've run into an issue with writing some code in c. My basic problem is that I am pressed for time and the code I am dealing with has lots of bugs which I have to "erradicate" before tomorrow evening.
The bigger part of the problem is that there is no adequate IDE that can do real time debugging, especially when using threads or spawning processes with fork(). I tried Mono, Eclipse, and finally NetBeans, and have concluded that those are very good but not for coding in C. More over the learning curve to utilize the command line debugger properly is quite steep. (Like I mentioned earlier... I am pressed on time.)
So, since I am a C# developer by profession I was wondering whether I can pull this off in VS2003/VS2005/VS2008/VS2010. If I abstain from using system calls, can I do this?
Of particular interest are FILE* descriptor and fread(), fclose(), fseek() methods. I know they are part of the standard C library, however are they tied to the platform itself? Are the headers the same in Linux vs Windows? What about fork() or shared memory?
Maybe if I use VS2010 to build parts of the component at a time (by mocking inputs and stuff), debug those, and then migrate the working code in the overall Linux project would prove most useful?
Any input would be greatly appreciated.
The bigger part of the problem is that there is no adequate IDE that can do real time debugging, especially when using threads or spawning processes with fork().
The Eclipse CDT would probably have the best overall support for C/C++ development and integrated debugging.
Note that multithreaded and multiprocess debugging can be difficult at the best of times. Investing in a good logging framework would be advisable at this point, and probably more useful than relying on a debugger. There are many to choose from - have a look at Log4C++ and so on. Even printf in a pinch can be invaluable.
So, since I am a C# developer by profession I was wondering whether I can pull this off in VS2003/VS2005/VS2008/VS2010. If I abstain from using system calls, can I do this?
If you take care to only use portable calls and not Win32-specific APIs, you should be ok. Also, there are many libraries (for C++ libraries such as Boost++ that provide a rich set of functionality which work the same on Windows, Linux and others.
Of particular interest are FILE* descriptor and fread(), fclose(), fseek() methods. I know they are part of the standard C library, however are they tied to the platform itself? Are the headers the same in Linux vs Windows? What about fork() or shared memory?
Yes, the file I/O functions you mention are in <stdio.h> and part of the portable standard C library. They work essentially the same on both Windows and Linux, and are not tied to a particular platform.
However, fork() and the shared memory functions shmget() are POSIX functions, available on *nix platforms but not natively on Windows. The Cygwin project provides implementations of these functions in a library for ease of porting.
If you are using C++, Boost++ will give you portable versions of all these system-level calls.
Maybe if I use VS2010 to build parts of the component at a time (by mocking inputs and stuff), debug those, and then migrate the working code in the overall Linux project would prove most useful?
You could certainly do that. Just be mindful that Visual Studio has a tendency to lead you down the Win32 path, and you must be vigilant to not start using non-portable functions. Fortunately the library reference on MSDN gives you the compatibility information. In general, using standard C or POSIX calls will be portable. In my experience, it is actually easier to write on *nix and port to Windows, but YMMV.
Looks like I am the first to recommend Emacs here. Here is how Emacs works. When you install it, it is simply a text editor with a lot of extensions(debugger and C font-locking are included by default). As you start using it and install the extensions you miss, it becomes more than just an editor. It grows to become an IDE very soon and easily, then on to something that can eschew the OS under one frame.
Emacs might take long to learn, in the mean time, you could use Visual Slick Edit if you are not pressed on the cost part. I have used it on both platforms and seen it work good with version control, tags, etc.
Perhaps Code::Blocks? I love it and while it says it's for C++ it is, of course, very good for plain C as well.