I need to point out obvious conflicts with a similar change by @antranigv_freebsd.am https://reviews.freebsd.org/D38826

wouldn't cfname=='-' hit this line when there the glob doesn't find anything?

I see what you mean, and yes, you are right!

I see, in that case, maybe this if (g.gl_pathc == 0) should go both after the loop and after the if at current L179, else this is a regression when instructing jail to read from stdin, and not having any other config files ^^.

nit: for consistency, and to avoid potential bugs use {} with if even when there is a single statement.

check_glob function name is a bit ambiguous: something like check_glob_err would be better

consider zero-initializing structs for safety, i.e. glob_t g = {0};

consider moving magic strings to either #DEFINE or static const to allow future re-use and avoid typos and duplication.

tentative: post-increment seems to be a more popular option in the tree, i.e. i++

same: consider explicit value comparison for non-boolean types,

consider doing explicit value comparison, i.e.:

if (yyparse() != 0 || yynerrs != 0) {

if I am not mistaken, this can lead to a situation where a file is parsed twice. if (op & JF_CONF_ALL) { condition does not exclude this one, so both can potentially be true, and cfname can have the last value set by the for loop a few lines above.

hint: this memset can be avoided by zero-initializing the struct at declaration stite, see my comment above

same: consider explicit value comparison for non-boolean types,

same: consider explicit value comparison

same: consider explicit value comparison

nit:
negation of integer is confusing, docf is used as a boolean, but has integer type. IMHO converting docf to boolean and then using

doc = Rflag !=0;

or at least we can be more explicit:

doc = Rflag > 0 ? 0 : 1;

extra tab, ruins the alignment

This patch supersedes the one by Antranig, so we both agreed to work on this one

Why whas the order of includes changed?