It depends in part on what you mean by 'quality C' code.
One important aspect of the program is "does it do what it was designed to do"? That is hard to measure, but is crucial.
Then you need to know whether the code is acceptable to compilers - using the set of GCC compiler options provided by Cristoph would indicate that the code is in good shape. (Although I would quibble over -Wno-long-long
, that depends on where your code might need to be be moved to).
The code layout is important. Is the code readable by humans as well as compilers? Is the layout uniform? Is it in one of the standard formats - there are several, all with major followings, and as long as you use one of them consistently, the code should be fine. Is it appropriately commented? That means enough comments, but not too many! The file should have a header comment indicating what's in it - and probably who wrote it, and maybe the licence under which it is distributed. There have been multiple questions on SO about that, including Professional #include comments. Writing code to a good layout standard is routine after a short time, though.
Documentation may be relevant - usually is relevant. How would someone else know that the code exists, what it does, how to use it, when to use it, when not to use it?
The code should be written with good enough algorithms - it should not use exorbitant amounts of memory, disk, or CPU time. It should also not leak resources. There's also no point in wringing the last CPU cycle of performance enhancement out of a routine that will be used once per run of a program, for a few milliseconds, when it starts up, unless you can demonstrate that it is a performance bottleneck for the program as a whole.
Wouter van Nifterick has given an excellent set of pointers too.