Thanks for the PR -- unfortunately, I don't think this is the right way to go. The "testrunner" binary, for instance, will be unable to find its configuration file.

The updated condition is still non-functional. Will keep at it and let you know when it may be ready for review again.

Okay. I have two possibilities that could solve this issue without breaking compatibility:

• Create a separate function that mirrors lwan_init_with_config() almost exactly save loading a config file
  • (possibly) extract the common parts of these two functions to a helper function to avoid repetition and fragility
• Add a boolean flag to the config struct that disables loading a config file
  • modify lwan_init_with_config() to respect this flag

If the boolean flag route makes more sense, then we would need to decide if it should disable all config file loading or just disable searching for a default config. I.e., it could just disable searching for progname.conf if config->config_file_path is NULL (which is the specific bit of functionality that I am trying to avoid). Obviously then, default_config would set this value to be true to preserve backwards compatibility.

Do either of these ideas sound reasonable? Both should hopefully manage to accomplish what I'm looking for without modifying behavior that anyone else is relying on.

So the issue you're facing here is that you're bothered by the warning message that the configuration file can't be opened. Lwan works fine otherwise.

A simpler solution that do not require changing the API or introducing another initialization function is just changing the warning message to a debugging message, so that it's only displayed on debug builds. Would that be OK?

The warning is part of it, but I'd also like to be able to know that it's not trying to load a config file at all (call me a control-freak if you'd like, :P). But, I should say this is not make-or-break for me. Having the warning not show up does sound pleasant, but even leaving it be would be fine if this seems like a total non-issue :)

I am considering this closed pending a better solution (though I'm not worried about it).