Thread: Complete reference

I read the book thread, is the book 'A reference manual' by Harbison and Steele a true reference? I wanted to post there but its closed.

I have books for learning with explanation and examples, but they don't cover everything and its not always handy to use that to quickly lookup how something works.

So basically what I want is an exhaustive reference book I can keep on my desk to quickly look something up, no lessons but function prototypes, concise explanation, short example perhaps, nothing more.

I was hoping something like that was available online. The closest thing I found is this, but its not complete.

Thanks!

I'm with Prelude on this; the draft C standards (ANSI C aka C89, C99, and C11) are the best reference for C in general.

For C library functions, I rely mostly on the Linux man pages project. Although it has "Linux" in the name, the man pages themselves all have a "Conforming to" section, which will tell you which standard (be it C89, C99, C11, POSIX.1, or something else) the functionality described is based on.

Most non-Windows systems provide many of the POSIX.1-2008 features in their C libraries. This includes functions like robust file tree walks using nftw(), reading input line-by-line without inherent line length limitations using getline(), looking up files based on a search pattern (glob pattern) using glob(), applying regular expressions to find and extract text data using regex(), and so on. A lot of typical tasks learning C programmers struggle with, are much easier to solve using these; they are also very, very practical with more complex application and library programming -- not to mention powerful.

(I do so wish this forum would get a POSIX.1 C subforum, for discussion on how to accomplish many of the mundane tasks with ease using POSIX functionality. Just because one company, Microsoft, is irrationally hostile towards all standards it cannot subvert, like POSIX, it does not mean users and developers should avoid using them.)

What I am trying to point out, is that there is no one complete reference.

Besides, if someone claims to be the be-all, end-all repository of information on some subject, they are absolutely lying, and you should not trust them. This includes all handbooks. For one, have you ever seen any book with more than a dozen pages, with no typos or logical errors? And one that magically stays up to date? I haven't.

Be critical of all information sources. Use as many as you can, constantly evaluating their reliability in each facet of the problem at hand, in parallel, for best results.

There's also the old steam driven method of writing your own summaries as you go.

Thanks everyone!

Both the drafts document and the Linux man pages project look great, they will help me greatly and they can be searched through. I'm on Linux btw.

The drafts PDF is not indexed however (ie, can't click on index numbers to jump there). Still, its great.

Maybe these should be included in the book thread. I can't imagine anyone learning a language and not have a refence companion along his/her side.

Originally Posted by Prelude

sufficient for the unwashed masses.

Hey! I take offense at that. I wash myself every day. With soap, too. Us masses aren't unwashed, we just lack the unfair privileges available to those who have the money to tweak the rules (or pay for interoperability information).



Thinking about rich elitists, hmph. I don't truck with them. Mainly because I don't have a truck or a driving license.

Ahem.

Gemera has a very good point, too. I personally have a README.txt file in most of my test project folders, where I put relevant notes and interesting links, as well as the details of the math I used.

I've been thinking of starting to put those up at my own web page, project by project.

I for one am not at all convinced that paid for information is any more reliable than free information. In particular, C compilers do not exactly follow what I understand the standard to be, because the text of the standard is sometimes up for interpretation, revised later, or simply not followed for practical reasons. The same applies to POSIX.1 too, and all other standards. The alignment of malloc() results for nonstandard vector types, and whether %n counts as a conversion in the *scanf() family of functions being very good examples. How many of us use ISO-8601 format for logging date and time, but drop the annoying T in beween, just using YYYY-MM-DD HH:MM:SS.uuuuuu UTC instead? Practice and results trump theory.

Originally Posted by Prelude

Why drop $200 (last I checked) on the official release when the free draft is sufficient?

Exactly. 248€ from my local standards association, Finnish Standards Association.

Originally Posted by Prelude

For my implementation of the standard library I've so far only used the draft since all of the relevant information seems to be present.

That sounds very interesting. I assume it's freestanding? Which OSes/kernels does it support? Architectures/ABIs?

I've been thinking about writing a small freestanding library to replace the standard C library, for writing specific types of service daemons in C. For example, credentials (process owner, group, supplementary group, and capabilities) are task specific in Linux; the C library just modifies them for all threads in the process internally. This means that it would be quite possible to have a threaded server, with credentials being specific to each thread, making filesystem access checks much easier. (I'm specifically looking at paranoid approach to security: only allow access to files if the owner and group are specifically whitelisted, but I also don't want to make it the bottleneck.) Add simple threading services based on clone() and futex(), and helpers to make memory-mapping files, and descriptor passing via Unix domain sockets easier. (That's just on the library API side; it's just currently so complicated to do that it's easy to get wrong. Especially stuff like SIGBUS handling due to files truncated/becoming unavailable.) And finally, support for true async I/O as implemented in the kernel (submit I/O, and it'll occur sometime later).

I've been wondering how much pain it is to maintain/port the kernel interface across architectures. The Linux kernel ABI is surprisingly stable; I'm not worried about that. Although AMD64 (x86-64) is prevalent now, I think 64-bit ARM (aarch64) variants will be important for me in the future, so porting/maintaining will be an issue.

I'd prefer not to have to maintain the ABI glue in assembly; do you?

Originally Posted by Prelude

Let's go with somewhere between no and hell no.

For Linux, the kernel ABI varies from architecture to architecture, and you do need wrappers written in (inline) assembly to move function parameters to correct registers et cetera; the kernel ABI may not match the C ABI for an architecture.

This, of course, delves deep into compiler behaviour, well beyond what C standards dictate, and as such, is a pain to maintain: you basically would have to check each new compiler version. The GCC folks are harsh, and don't mind breaking existing code, if they can justify the change based on the ISO standards; this means they do change internal behaviour without telling anyone about it, so it takes a silicone-nerved person to keep up with it.

Besides, GCC would generate better code, if the functions were defined as static inlines in a header file, implemented with an inline assembly wrapper. You won't be able to interpose such functions, though -- which for a security-oriented approach might not be a bad thing.