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.
Related
I'm just now getting into threading and specifically I want to learn POSIX threads, and everything about them. As implemented in Linux. I'm looking for resources to learn about them but many of those resources are very old. Some of them date back to
1996 with PThreads Programming: A POSIX Standard for Better Multiprocessing (A Nutshell Handbook)
1997 with Programming with POSIX Threads
I am not asking for resources. Being that these two books are so old, I'm wondering how on topic they'd be. How is the POSIX API versioned? On Wikipedia all I see is this,
POSIX Threads is an API defined by the standard POSIX.1c, Threads extensions (IEEE Std 1003.1c-1995).
I'm not sure if that means that there are no updates since 1995 to the threading parts of POSIX or not? Is there any way to judge the relevancy of the material?
At the very bottom of the Wikipedia page you reference in the "External Links" section, you will find a link to the current Posix specification of pthreads.h, which includes a history of changes. There have been a few, but the basic principles are intact. So the books you mention are probably still good learning materials. (I still have a well-thumbed copy of Programming with POSIX Threads on my bookshelf.)
As is mentioned in the comments below, C11 provides atomics and thread-local storage, which is implemented by GCC since 4.9. (Thread-local storage was previously available in GCC as an extension, so it is not that new.) The existence of thread-local storage reduces the need for the Pthreads thread-local storage interfaces, but that is a small part of the Pthreads library (and, although thread-local storage is easier to use and syntactically more convenient, it doesn't really change program structure much.)
C11 also specifies an optional threads.h header which contains threading function similar to Pthreads. However, glibc does not include this header, and the use of Pthreads is still pretty well universal, although both open- and closed-source threads.h implementation do exist. (For open source implementations, see the musl library and/or the FreeBSD implementation, available since 10.0.) Conceptually, the C11 interfaces are very similar to Pthreads; obviously, they have different names and in some cases they are simplified. However, once you've mastered Pthreads, you should have little trouble understanding any C11-threads programs you come across.
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 want to write a library that is dynamically loadable and callable from C code, but I really don't want to write it in C - the code is security critical, so I want a language that makes it easier to have confidence that my code is correct. What are my options?
To be more specific, I want C programmers to be able to #include this, and -l that, and start using my library just as if I had written it in C. I'd like programmers in other languages to be able to use their favourite tools for linking to C libraries to link to it. Ideally I'd like that to be possible on every platform that supports C, but I'll settle for Linux, Windows and MacOS.
Anything that compiles to native code. So you might Google for that - "languages that compile to native code." See, e.g., Programming languages that compile to native code and have the batteries included
C++ is often the choice for this. Compiles to native code and provided you keep your interfaces simple, easy to write an adapter layer.
Objective C and Fortran are also possible.
It sounds like you are looking for a language with ABI compatibility or which can be described as resulting in native code. So long as it can be compiled to a valid object file (typically an .obj or .o file) which is accepted by the linker, that should be the main criteria. You also then want to write a header file as a convenience for any client code which is written in C (or a closely related language/variant thereof).
As mentioned by others, you need a pretty good reason for choosing a language other than C as it is the lingua-franco of low-level/systems software. Assembler is an option, although harder to port between platforms. D is a more portable - but less widespread - alternative which is designed to produce secure, efficient native code with a minimum of fuss. There are many others.
Almost every security critical application I know of is written in C. I don't believe that there are any other language that has higher real status in producing secure applications.
C is being said to be a poor language for security by people who don't understand.
If you want C programmers to use your library, use C. Doing anything else is tying one hand behind your back whilst trying to walk on a balance beam (the gymnastics equipment). Sure, there are dozens of other languages that are CAPABLE of interfacing to C, but it typically involves using a C layer and then stuffing the C data types into a language specific data type (Java Objects, Python Objects, etc, etc), and when the call is finished, you use the same conversion back to a C data type. Just makes it harder to work with, and potentially slower if you don't get all the design decisions right. And people won't understand the source code, so won't like to use it (see more about this below).
If you want security, then write very good code, wearing your "security aspects" hat firmly on at all times, find a security mailing list or website and post it there for review, take the review comments on board, understand the comments, and fix any comments that are meaningful to fix. Distribute the source code to the users, so people can see what your code does. Those that understand security will know what to look for and understand that you have done a good job (or a bad job, whichever is applicable) - and those who don't will hopefully trust the right pople. If it's good, people will use it. If it's "hidden", and not easy to access, you won't get many customers, no matter what language you use.
Don't worry, you won't reveal anything more from releasing source. If there is a flaw in the code, and it is popular (or important) enough, someone will find the flaw, even if you publish only binaries. For those skilled in reverse engineering, not having source code is only a small obstacle.
Security doesn't stem from using a specific language or a specific tool, it stems from good design and good basic understanding of the problems with security.
And remember security by obscurity (whether that means "hidden source code" or "unusual language" or something else obscure) is false security.
You might be interested in ATS, http://ats-lang.sourceforge.net/. ATS compiles via C, can be as efficient as C, and can be used in a way that is ABI-compatible with C. From the project website:
ATS is a statically typed programming language that unifies implementation with formal specification. It is equipped with a highly expressive type system rooted in the framework Applied Type System, which gives the language its name. In particular, both dependent types and linear types are available in ATS. The current implementation of ATS (ATS/Anairiats) is written in ATS itself. It can be as efficient as C/C++ (see The Computer Language Benchmarks Game for concrete evidence) and supports a variety of programming paradigms
ATS's dependent and linear type system helps produce static guarantees about your code, including various aspects of resource management safety.
Chris Double has been writing a series of articles exploring the power of ATS's type system for systems programming here: http://bluishcoder.co.nz/tags/ats/. Of particular note is this article: http://bluishcoder.co.nz/2012/08/30/safer-handling-of-c-memory-in-ats.html
This document covers aspects of calling back and forth between ATS and C code: https://docs.google.com/document/d/1W6DYQApEqKgyBzMbvpCI87DBfLdNAQ3E60u1hUiMoU0
The main downside is that dependently-typed programming is still a daunting prospect, even for non-systems programming. The syntax of the language is also a bit weird: consider lexical quirks such as the use of abst#ype as a keyword. Finally, ATS is to some degree a research project, and I personally don't know whether it would be sensible to adopt for a commercial endeavour.
Theoretically, it's going to be Fortran: less indirection (as in: my array is [here], not just a pointer to here, and this is true of most but not all of your data structures and variables).
However... There are many gotchas and quirks in Fortran: not, perhaps, as many as in C but you probably know your way around C rather better than Fortran. Which is the point behind most of the comments saying 'Know your code' - but do you really know what your compiler is doing?
Knowing you, I'm prepared to take it on trust that you do, for C. Most programers don't. You do not know and cannot know what a local JVM or JIT compiler does, and that's a black hole in your security model if you're using Java or C# r scripting languages.
Ignore anyone who tells you that the hairy-chested he-men of secure computing write their own assembler: they probably don't even know the security errors they're making in any and all nontrivial projects they release. Know your compiler, indeed.
You could write it in lua - providing a C API to a Lua library is relatively straight forward. C++ is also an option, though of course you'd have to write C wrappers and make sure no exceptions can escape your functions. But honestly, if it's security critical the minor inconveniences of the C language shouldn't be that much of a big deal. What you really should be doing is prove the correctness of your program where feasible, and test extensively where it's not.
You can write a library in Java. JNI is normally used to call C from Java, but it can be used the other way around.
There is finally a decent answer to this question: Rust.
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.
I thought I wanted to use GSS-API, but now am not so sure, since I'm having a hard time finding good sample code for a trivial client/server pair. Sun has documentation including sample code, but it's written specifically for their GSS API implementation, using a few proprietary functions not in e.g. the GNU GSS-API (and for which it's not immediately clear to me how to re-implement them against the GNU implementation). Plus, it's written in pre-ANSI C, with K&R function declarations and so on (I had no problem converting the declarations, but it did make me think the Sun example code may be so old as to be irrelevant).
Have you used the GSS-API in an application in, say, the last decade? Do you know of some self-contained tutorial with example programs that's worth reading?
Alternatively, maybe I'm on the wrong track and should try SASL instead. The GNU GSS-API author himself suggests as much.
For what it's worth, I'm using GCC on Linux, and have Kerberos set up already for other purposes.
Yes, you should absolutely be using SASL instead of GSSAPI. It is a much better supported protocol, and the libraries are pretty good. At the very least, you can think of it as a sanity-improving wrapper over GSSAPI, since that is one of the typical plugins implemented for SASL. The only reason you should consider using GSSAPI directly is to implement a SASL library. But don't do that. :)
SASL also has wide use. It is specified as part of IMAP and XMPP.
Are you implementing some custom protocol over TCP?
Sun uses the GSSAPI in their Java code. You can find a bit more information about it here:
Equivalent of 'gss_import_name' and 'gss_init_sec_context' methods in java?
Also you may want to look at the code implementation done by the folks at OpenJDK:
http://www.docjar.org/docs/api/sun/security/jgss/GSSContextImpl.html
They have published a full working example of GSSAPI written in Java.
Grant