

Show HN: Graph-based data storage REPL in C - jhedwards
https://github.com/incrediblesound/Graph-Reply

======
jotux
Some general feedback:

In C you separate your implementation from your interface with header files.
If you include .c files in .c files it will end up causing a lot of problems
and start making includes order dependent (like how your code will break if
you move #include "structures.c" down a few lines).

Generally you want a header file for each source file and put the stuff you
want to share with other files in there (prototypes, typedefs, etc). For
example, disk_utility.h would have prototypes for save_to_disk and
read_from_disk and then instead of including disk_utility.c in your replay.c
file you'd include disk_utility.h.

Without compiling the code I see a lot of things that are, at least, warnings.
When you're learning you really want to compile with -Wall and pay attention
to warnings.

It's a neat project and I hope you continue learning C, it's a great language.

~~~
jhedwards
Thanks for your feedback! I spent a lot of time chasing down memory leaks with
this project, which was fun, but clearly that's not the last of the hurdles
with C. My dream is to program space robots, which probably will never happen,
but I feel one step closer every time I build something in C.

~~~
LukeShu
I've made a pull request that contains a reasonable mount of feedback. I hope
it's useful and instructive!

~~~
e12e
Those are great reading, thank you (even if I have nothing to do with the
project :-). For others:

[https://github.com/incrediblesound/Graph-
Reply/commits?autho...](https://github.com/incrediblesound/Graph-
Reply/commits?author=LukeShu)

------
axoltl
C is not a safe language sort of by definition, so you always have to consider
all the possibilities. For example, you use sscanf in places, with fixed sized
buffers. What happens if someone were to pass a lot of data into your program?
What happens if the on-disk structure gets corrupted and a 'type' becomes more
than 5 characters?

