Config file parser for lists

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> It is normally done when innd starts:
>
>  if (!foundxref || !foundxreffull) {
>    syslog(L_FATAL, "%s 'Xref:full' must be included in %s", LogName, SCHEMA);
>    exit(1);
>  }

Ah, yes.  Okay.  I should have remembered that.

> Can a header be listed twice?  (It is not mentioned in RFC 3977.)

I think so.  It's just pointless.

> Hmm...  When we added that in innfeed (for the status file):
>
>  if (host->ipAddrs) {
>    int  i;
>    char ip_addr[INET6_ADDRSTRLEN];
>    char *family;
>
>    for(i = 0; host->ipAddrs[i] != NULL; i++) {
>      switch(host->ipAddrs[i]->sa_family) {
>        case AF_INET:
>          family = xstrdup("IPv4");
>          break;
> #ifdef HAVE_INET6
>        case AF_INET6:
>          family = xstrdup("IPv6");
>          break;
> #endif
>        default:
>          family = xstrdup("????");
>          break;
>      }
>
>      network_sockaddr_sprint(ip_addr, sizeof(ip_addr),
>                              host->ipAddrs[i]);
>      fprintf(fp, "   Addr %-2u: %-4.4s  %s\n", i+1, family, ip_addr);
>    }
>  }
>
> is it necessary to free(family) at the end of the function?
> Isn't it done automatically?

Yes, you have to free it.  Only allocations with alloca are automatically
freed at the end of the function.

In this particular case, I don't think you want to use xstrdup at all.
Instead, just:

    const char *family;

    /* ... */

        family = "IPv4";

and so forth.  It's always a constant string, so no need to allocate
memory and make a copy.

>> What I'd suggest doing is removing Xref from user configuration
>> entirely.  INN requires it.  We should just make it impossible to
>> configure INN to not include it in the overview.  The easiest way to do
>> that, I think, is to define extraoverview as all overview fields
>> *after* Xref and just unconditionally always add Xref as the first
>> field after the standardized set.

> OK.  I was following your suggestion in
> <http://inn.eyrie.org/trac/ticket/101> but well, not mentioning Xref is
> also fine.

Yeah, I think not listing Xref is a better idea.

The plus side to listing Xref is if we ever want to support removing Xref
from the overview, but the amount of work that requires due to losing our
ability to chase crosspost references in INN's code is rather significant
and I'm not sure there's much utility.

> Have a nice week-end (and a good night -- it is very late where you are!).

Yeah, was up early for a network migration.  :)

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.