Reducing use of fixed-size buffers in source

[maxim-zhao]

Somewhat inspired by issues with MAX_NAME_LENGTH, I'd like to make some PRs to reduce the use of static buffers, of which there are many, in favour of more dynamically allocated memory. This is technically a bit slower but I think negligibly so.

For my first round, I've changed the .stringmap directives I wrote to duplicate strings by allocation instead of copying into a fixed MAX_NAME_LENGTH + 1 buffer. This is simple enough but I wished for a strdup function - unfortunately that's POSIX and C23, not ANSI. @vhelin, is it OK to introduce such a thing? It's as trivial as you might think (name chosen to avoid conflicting with strdup):

char * string_duplicate(char * p) {
    char* result = calloc(sizeof(char), strlen(p) + 1);
    if (p != NULL) {
      strcpy(result, p);
    }
    return result;
}

Where should such "utility" functions live?

Next I felt I didn't like the use of g_error_message for error printing with formatting. I changed print_error() to have varargs, and perform the formatting on the inside; I also reordered it to void print_error(int type, char *error, ...). Again, any feedback on this? It layers on top of the previous item so I'd need to disentangle to make it a separate PR. In two places it's used as a temporary buffer, unrelated to error messages; I changed these to string duplications instead.

[vhelin]

Shouldn't that NULL check be like if (result != NULL)? :)

Anyway, that's the trivial part. I'd say utility functions should be there where they are mostly used. Not want to go through the hassle of introducing a new .c file in the project as historical makefiles would need a lot of updates... If someone wants to do that, add something like utils.c, then feel free to do so. :)

If .STRINGMAP does a calloc() every time you call it then I'd say this is not the way we should proceed. What would be better is that there'd be a system that'd give out reusable buffer[MAX_NAME_LENGTH + 1]'s to those who need them, and then recycle them when the code that borrowed one returns the buffer. And that system should allocate more such reusable buffers on demand.

[maxim-zhao]

The string mapping functionality only allocates strings when loading a file via .stringmaptable, don't worry.

I'll put (a fixed version of) string_duplicate next to strcaselesscmp.

My thought is that if you want to have a string copy of some sort as a parsed token, it should (eventually) be parsed in somewhat flexibly (up to the limits of memory I guess) and then if you want to take a copy, you take a copy by allocating a right-sized buffer and free it later. For example the existing structure "object" holds its name:

struct structure {
  char name[MAX_NAME_LENGTH + 1];
...
}

This can equally well be char* name, taken as a copy and cleaned up later. Several other structs have a similar pattern. (On a separate note, it looks like this could be held using a hashmap, but I need to reign back my desire to fiddle with things.)

[maxim-zhao]

Broadly, to raise MAX_NAME_LENGTH limits I need to change all the places where names can go, before I can change the actual parser that reads in tokens. So, for example, tackling the error messages buffer (#474) is necessary because we report "named things" into it; changing the limits for certain isolated directives is relatively straightforward (#473, #476) but gives no benefit yet. Some named items get copied into yet more fixed-size buffers and into other named items, so I need to work on them in the correct order of dependencies.

It'd much easier if we could use C++ strings 🙊

[vhelin]

C++ is not an option, sorry. :)