Is it completely unheard of to have a .c file dedicated to just data? In my case, I'd be using it for global variables that are shared across two other .c files. Here's specifically how I'm using it.// serverth.hstruct serverth_parameters {    struct { // right now, this is the only struct needed        char * root,             * user,             * public,             * site;    } paths;    // I anticipate needing another struct here};#ifndef SERVERTH_SOURCEextern struct serverth_parameters parameters;#endif// serverth.c#define SERVERTH_SOURCE#include serverth.hstruct serverth_parameters parameters = {    .paths = { // macros are actually used here        /srv,        /user,        /public        /site    }};parameters is a struct that's used for a websockets server, in two files:One for HTTP (uses parameters.paths.site)Two for proprietary protocols (both use .paths.user, one uses paths.public)Is this a bad practice? Do people do this? Or, is it more conventional to just keep the data in the source file in which it is most relevant?
.c FIle Dedicated to Data
programming practices;c
In general I'd be wary of dumping ground files, where one would start listing global variables or long lists of #defines.However, if by globals you actually meant that these globals would be constants, then that would seem acceptable, as long as they are structured and re-grouped in meaningful patterns, and that the extent of their reuse justifies to extract them to a separate file.If these conditions aren't satisfied, then I'd usually restrain them to the file where they're expected to be used, if possible.Include GuardsOn a different note, I don't know how your files are compiled and what build system you use, but you might want to use compilation guards of the form:#ifndef MY_MODULE# define MY_MODULE/* stuff here */#endif