

CCAN - Comprehensive C Archive Network - conductor
http://ccodearchive.net/

======
kephra
This so called CCAN is missing the most important point of CPAN: Minimum code
quality in terms, that code must compile same way, install same way, test
itself same way, and have a documentation that describes how to use it. In
addition CPAN provides extended code quality by PAUSE and CPAN testers.

~~~
RustyRussell
Hi Kephra,

Perhaps the site isn't clear, but this all exists.

1) All CCAN modules compile with by providing a config.h and compiling * .c
(if any). Metadata (eg. linking requirements, other modules) is in the _info
file.

2) These are not libraries, though they can be compiled like that of course.
So install is outside scope.

3) Testing is done in the modules' test subdir. compile-ok* .c and compile-
fail* .c tests are what you'd expect. run* .c are compile-standalone-and-
execute-with-0 status tests. api* .c are compile-with-module-and-execute
tests.

4) The documentation standard is in the form of parseable but human-readable
comments in the header files and _info.

The ccanlint tool will do most of this for you.

I hope that helps clarify.

------
makmanalp
This is awesome, should add
[https://github.com/attractivechaos/klib](https://github.com/attractivechaos/klib)
to it.

Would be awesome to merge this with:
[https://github.com/clibs/clib](https://github.com/clibs/clib)

------
gopalv
I used exactly one module from CCAN in the past - failtest
([http://ccodearchive.net/info/failtest.html](http://ccodearchive.net/info/failtest.html)).

And that's a simple idea, done well (and helps me hit the usually untested
code paths).

If I had to still work a lot with C (I mostly write bits wrapped in
JNI/Python/PHP exts), I would say that the hashtable, list and INI parser
would be bits I would never want to reinvent again.

~~~
RustyRussell
Hey, good to hear someone else finds that useful!

Making it more generic, so you can plug in your own failing functions, is
somewhere on my TODO list. That would make this much nicer.

~~~
eaxitect
Sure this is useful unless one have "not invented here" syndrome.

------
danellis
If it's for snippets of C code, then I point out the following alternative:
[https://gist.github.com/search?q=language%3Ac](https://gist.github.com/search?q=language%3Ac)

------
amboar
Previous submission:
[https://news.ycombinator.com/item?id=6546700](https://news.ycombinator.com/item?id=6546700)

------
ape4
I looked at some of the code and there are too many malloc()s for my liking.
When I write in C++ (yes I know this is C) I always avoid malloc()s and new's.
Eg let the language free the variable by going out of scope, use STL. I would
like to see a library that follows those practices.

------
z3phyr
What will be the state and essence of C programming language in the forseeable
future? Will it be as useful as it is today? Most importantly, will people use
it for major projects?

~~~
eaxitect
I think C will continue to be basis unless a new system come out with some
other language/platform (like Go) and this new system is proven to be more
reliable and faster than C-based platforms. On the other hand, there are also
politics of this choice, i.e. there are standards, industry groups, etc. all
based on C. These are should be replicated on this new language/platform.
Tl;Dr; All have to be start over again what we have since UNIX.

------
ape4
Something C was missing.

------
monokrome
Who chose that yellow, and why?

~~~
amboar
Probably this guy, because he curates ccan:
[http://rusty.ozlabs.org](http://rusty.ozlabs.org)

~~~
monokrome
But why?!

~~~
sanarothe
Oh god agreed. The blog at least isn't blinding, but CCAN is.

I feel a bit like the kid who only likes the vidja-games with the fanciest,
flashiest graphics but I basically won't tolerate anything less than modern
style and typography anymore.

~~~
KC8ZKF
You should know all that style and typography that now makes you tumescent
will look old-fashioned in eighteen months.

