[RFC] Discuss placement of custom code inside/outside of config

[hanno-becker]

Currently, the only place where users can provide custom functionality is in their custom config. However, since the config is the first header to be included by all other mlkem-native headers, this prevents custom implementations to build on functionality provided by later headers. For example, it was noted in #1379 that a custom implementation could not refer to mlk_zeroize, because that would lead to a circular dependency config -> verify -> common -> config. In #1379, this is worked around by unconditionally calling mlk_zeroize in a wrapper macro defined later, but in principle the issue remains.

An alternative to custom code in the config would be for the user to specify the name of an additional header file that could be included separately from the config.

I'm unsure what the cleanest / most convenient approach is, here, so am opening this up for discussion.

@davidchisnall I'd appreciate your thoughts/experience here.

[davidchisnall]

I believe the headers are guarded, so that circular dependency should not be a problem:

config includes verify, verify includes common, common includes config, but the inclusion of config is guarded (I use #pragma once, the rest of the files use explicit #ifndef guards), so that include is a no-op. It should be fine to structure your config file as:

#ifndef MLK_MY_CONFIG
#    define MLK_MY_CONFIG

#    define MLK_THING_ZEROIZE_NEEDS

#    include <thing that provides zeroize>

void my_free(void*ptr, size_t size)
{
    mlk_zeroize(ptr, size);
    free(ptr);
}

#    define MLK_FREE(ptr, size) my_free(ptr, size)

#endif

[davidchisnall]

The other issue though is that (sorry, this is my fault) the config file is now public, whereas that example is including an internal one. That might be possible to guard on a macro set during the internal builds.

[hanno-becker]

Unfortunately, at the moment at least it doesn't work, because what's included by the source files is common -> config -> verify -> common, and since the guard for common is already set when verify includes it, it's dropped; which means that the default #define mlk_memset memset (if memset isn't overwritten) hasn't been processed when mlk_zeroize is processed, which uses mlk_memset. So some restructuring would be needed to make this particular case work.