[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-developers] Why old-school C?
From: |
Ed Baskerville |
Subject: |
[GNUnet-developers] Why old-school C? |
Date: |
Wed, 8 Jul 2015 12:16:23 -0700 |
Hi GNUnet devs,
I'm new to the list and to GNUnet. I got interested in the project after
hearing about the social networking app being developed, and after lots of
delay I'm devoting the next few weeks to getting better educated on how things
work. We clearly need a standardized, free lower layer for decentralized,
encrypted, anonymized/anonymizable networking, and one that's being
systematically analyzed for scalability and vulnerabilities--so GNUnet looks
pretty good.
My question: why is GNUnet development being done in traditional C style, with
raw pointers to structs, dereferencing, manual memory copying, etc.?
A related question: how hard would it be to make it safer?
If the answer is: we're on it; it's a main focus of upcoming development--then
just tell me so and ignore the rest of this email.
If not, I acknowledge that there are many reasons why a codebase would be in C.
It's still the only lingua franca we have, and certainly was when the project
started. We can catch some things with static analysis. The modular
architecture of the system probably limits the attack surface, so a mistake in
one component might be OK. And I suspect you're all very good C programmers.
But we all know that this kind of programming carries inherent dangers, and
that the dangers grow with the number of contributors and the size of the
codebase.
Plus, GNUnet seems to be transitioning from a research project to something
trying to take over the world, so it seems like now--before it's running on
millions or billions of devices--would be the time to change how things are
done.
We don't yet know what the safe lingua franca for the next generation is going
to be, but there are ways to avoid old-school C style while sticking to C. You
can limit all memory management to a tiny, safe, well-tested core API, use
fully opaque data types and associated functions, and automatically check
source code to enforce these conventions outside core regions.
Again, I think the GNUnet project is great, but this kind of code scares me.
I'd appreciate any thoughts, either on why I'm wrong and shouldn't be so
scared, or on how you're planning for things to evolve.
Ed
- [GNUnet-developers] Why old-school C?,
Ed Baskerville <=
- Re: [GNUnet-developers] Why old-school C?, Christian Grothoff, 2015/07/08
- Re: [GNUnet-developers] Why old-school C?, Ed Baskerville, 2015/07/08
- Re: [GNUnet-developers] Why old-school C?, Christian Grothoff, 2015/07/08
- Re: [GNUnet-developers] Why old-school C?, Nils Durner, 2015/07/08
- [GNUnet-developers] iOS/non-free platforms (was: Why old-school C?), Ed Baskerville, 2015/07/08
- Re: [GNUnet-developers] iOS/non-free platforms, hellekin, 2015/07/08
- Re: [GNUnet-developers] iOS/non-free platforms, Christian Grothoff, 2015/07/09
- Re: [GNUnet-developers] iOS/non-free platforms, Ed Baskerville, 2015/07/10
- Re: [GNUnet-developers] iOS/non-free platforms, hellekin, 2015/07/16
- Re: [GNUnet-developers] Why old-school C?, Jeff Burdges, 2015/07/15