Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: INN indentation (Russ Allbery)
2. Re: Discussion about Cancel-Lock support (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Sun, 17 Oct 2021 09:33:37 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> I've had a look but wanted to be sure of what to do.
> It seems like that all inclusions of "clibrary.h", or of both "clibrary.h"
> and "config.h", should be changed to only one inclusion of
> "portable/system.h".
> And "clibrary.h" moved to "portable/system.h".
I think that's right.
In my other packages, I leave in the include of config.h to be explicit
and because there are some files that don't need portable/system.h but
everything (pretty much) needs config.h. But this is just me being
pedantic and it's probably not worth maintaining that in INN.
> "portable/system.h" in rra-c-util uses:
> #include <config.h>
> "clibrary.h" uses:
> #include "config.h"
> Shouldn't the syntax with quotes be used? ("config.h" is not a system
> header)
My other packages use non-recursive make, and in that case I think it's
preferrable to not have the two different search paths for include files
in play (it tends to confuse me). Automake explicitly adds the
appropriate header search path automatically. The Autoconf manual
explicitly recommends this for config.h:
To provide for VPATH builds, remember to pass the C compiler a ?-I.?
option (or ?-I..?; whichever directory contains ?config.h?). Even if
you use ?#include "config.h"?, the preprocessor searches only the
directory of the currently read file, i.e., the source directory, not
the build directory.
With the appropriate ?-I? option, you can use ?#include <config.h>?.
Actually, it?s a good habit to use it, because in the rare case when
the source directory contains another ?config.h?, the build directory
should be searched first.
In INN, we have to use "" for make depend to work, and make depend in turn
exists because we're not using Automake.
That reminds me that I want to take a moment now that everything is in Git
and switch the INN build system over to Automake, since I think it would
get rid of a bunch of maintenance gotchas and chores that currently have
to be done manually. It will raise a few questions, though, such as
whether the additional human-readable information in MANIFEST is useful
when it's no longer necessary to generate a distribution.
> In HACKING:
> "clibrary.h" does also include "config.h", but it's somewhat poor form
> to rely on this; it's better to explicitly list the header
> dependencies for the benefit of someone else reading the code.
> :)
> We can get rid of that paragraph then.
Yes.
> Also, from TODO:
> * The include files necessary to use libinn, libstorage, and other
> libraries should be installed in a suitable directory so that other
> programs can link against them. All such include files should be under
> include/inn and included with <inn/header.h>. All such include files
> should only depend on other inn/* header files and not on, e.g.,
> config.h. All such include files should be careful about namespace to
> avoid conflicts with other include files used by applications.
> Isn't it already done?
> All headers in include/inn only include headers also in include/inn, which
> never include "config.h".
conffile.h and innperl.h are still at the top level. (And ppport.h,
although it's a bit of a weird case.)
> I think the namespace is ok (I'm not aware of any complaints about it).
> Unless I am missing something, there isn't any work to do for that task,
> is it?
So, the problem with the namespace is that we create a shared library that
has tons of random functions exported from it that don't share any common
prefix, and hence sprawl all over the C function namespace. (Stuff like
concat, all the buffer_* stuff, etc. Often they have their own namespace,
like QIO, but sometimes they don't nad it's not really consistent.
For a well-behaved shared library, ideally all that stuff should have inn_
or INN_ prefixes. But that's a huge pain in the ass to do because it's
little changes all over the source base, and I'm not sure if it's a good
use of time. This is part of why, for example, the Debian packages
install the libinn shared library out of the normal library search path,
since it's not entirely a well-behaved shared library. (Also it doesn't
have symbol versioning.)
Another approach rather than rename everything would be to shrink the
symbols provided by the shared library down considerably to only things
that make sense for external programs seeking to have API access to INN
data files, namespace all of those, and then hide all the other symbols.
This would probably involve creating a separate static library with the
internal utility code like buffer and linking that with all the
executables. This is what I do for other projects with a shared library
to keep the shared library ABI minimal. Again, not sure it's worth it,
and it would break any out-of-tree software that really uses libinn for
its random utility functions.
Switching the build system to Automake would make it way easier to do this
sort of thing, so even if we did want to do all of this, we should do that
first.
> Finally, we already have "inn/system.h", with a few configure-time options
> set (like INN_HAVE_INET6 or INN_HAVE__BOOL) needed by INN headers.
> It is notably included by "inn/defines.h" which only include 3 header
> files. Time has come to get rid of "inn/defines.h" at the same time,
> and just include the necessary headers instead of it.
Yup, that would be great.
> I also see that the next clang-format release (13) will permit aligning
> array of structs with for instance:
> AlignArrayOfStructures: Right
> struct test demo[] =
> {
> {56, 23, "hello"},
> {-1, 93463, "world"},
> { 7, 5, "!!"}
> };
> The current formatting breaks them badly...
> I believe this new style option will permit removing a few /* clang-format
> off */ comments in the code.
Oh, excellent, looking forward to that.
Thank you for tackling this reformatting!
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 2
Date: Sun, 17 Oct 2021 09:57:26 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> It may be the right moment to do the most appropriate thing as for
> configuration files. We currently have only 1 file (inn.conf) that uses
> the internal new parser. All the other files have various different
> parsers.
> For the new secrets.conf file, we can:
> - either directly use YAML for it, and then plan on migrating other
> configuration files to YAML, including inn.conf;
> - or make the parser generic for several files, and then re-use it for new
> config files. It normally suits our needs.
I think the long-term goal, if we adopted YAML, would be to provide a YAML
version of all of the config files (with schema checking, which would be
lovely), and then provide some sort of conversion from the old format to
the new format.
Personally, I'd be happy to never have to write cryptic configuration lke:
news.uu.net/uunet\
:*,!junk,!control,!control.*/!foo\
:Tm:innfeed!
again and instead be able to write something like:
peers:
news.uu.net:
groups: "*,!junk,!control,!control.*"
pathalias: uunet
distributions: !foo
innfeed: true
This is the kind of disruptive change that tends to irritate people who
have used INN for decades, though. We could of course continue to support
both the old and new format indefinitely, but that doesn't seem great in
terms of code complexity. I think the question is whether having a
cleaner config syntax with more human-readable options and schema checking
is enough of an advantage over, say, the current cryptic newsfeeds syntax
to be worth introducing a whole new config syntax after all this time.
Of course, stuff like newsfeeds could be way down the list and we could do
the other files that are already closer to YAML first, but I think
newsfeeds is where the largest advantage is.
(If we did something like this, it also opens the interesting possibility
of rethinking how configuration is broken up between files. It's pretty
irritating right now to have to modify three different files with entirely
different syntax to add a new peer, and we could fix that. That was part
of my original thought process in writing the new config parser, but then
I never followed through.)
It's a huge project, though.
> As far as I see, inn.conf has already a YAML-like syntax except for
> vectors. We still haven't used group tags, and I doubt people use
> several parameters in the same line separated with semicolons.
> Therefore switching it to YAML should not be too much difficult unless
> of course we do at the same time a deeper refactoring and urbanization
> of all the configuration variables present in inn.conf, and that's more
> challenging.
Right. Yeah, the "new" parser (if you can call anything that old new) has
a somewhat YAML-like syntax already.
> The drawbacks I would see for YAML is that we add a library dependency to
> libyaml, hoping it is available in all the platforms we support (libyaml
> seems more wide-spread than libfyaml).
Yes, this is a potentially serious drawback for folks who are building INN
themselves on platforms other than Linux.
> And naturally that it would make the current inn.conf parser useless
> after migrated to YAML. Which is a loss of a great deal of hard work.
Oh, don't worry about that, it was mostly my work and I don't care. :)
It was a good learning experience for me: I learned that I shouldn't write
my own configuration parser and instead use some standard language!
> And personally I like its way to write lists ([a b c]) more than YAML
> does (multi-lines).
Little known fact: [a, b, c] is also valid YAML!
This is the blessing and the curse of YAML; the language is absurdly huge
and there are multiple ways to do things. But, for example, valid JSON is
also valid YAML.
All of the following are equivalent in YAML:
foo:
bar:
- a
- b
- c
foo:
bar: [a, b, c]
foo: {bar: [a, b, c]}
"foo": {"bar": ["a", "b", "c"]}
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 134, Issue 6
*******************************************
