Hello Tim,

On Mon, 22 Jun 2020 at 18:56, Tim Düsterhus <t...@bastelstu.be> wrote:
>
> Lukas,
>
> Am 22.06.20 um 18:41 schrieb Lukas Tribus:
> > On Mon, 22 Jun 2020 at 18:16, Tim Duesterhus <t...@bastelstu.be> wrote:
> >>
> >> Fix parsing of configurations if the configuration file does not end with
> >> an LF.
> >
> > ... but it's also warning about it at the same time.
> >
> > So it's unclear to me:
> >
> > Do we support a configuration without trailing LF or not?
> >
> > If yes, there is no point in a warning (just as < 2.1).
> > If no, we should abort and error out.
> >
> > We can "just warn" if we plan to deprecate it in future release, and
> > at that point, explain that fact. But I find it strange to warn about
> > something, without a clear indication about *WHY* (unsupported,
> > deprecated, etc).
> >
> >
> > Thoughts?
> >
> I consider leaving out a trailing newline a bug for these reasons:
>
> [...]
> A non-terminated line thus is not a line and handling non-terminated
> lines is a bit wonky.

What you are explaining is that the behavior is basically undefined,
so in my opinion we should just flat out reject this configuration.
s/ha_warning/ha_alert ?

If we want to continue with a warning only (to not break older
configs), let's elaborate, because the warning just explains that the
line is not terminated, but not if and why that is actually a problem,
which I don't like to leave as an exercise for the reader (user).

ha_warning("parsing [%s:%d]: line is not terminated by a newline (LF /
'\\n'), this may lead to undefined behavior.\n",

ha_warning("parsing [%s:%d]: line should be terminated by a newline
(LF / '\\n'), otherwise undefined behavior may occur.\n",

Something like that?


But really, I think we should just reject this instead (then the text
suffices, because it actually stops working).



--
lukas

Reply via email to