gnunet-developers
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]