On Montag, 28. Februar 2022 15:06:07 CET Peter Maydell wrote:
> On Mon, 28 Feb 2022 at 13:58, Christian Schoenebeck
>
> <qemu_...@crudebyte.com> wrote:
> > On Montag, 28. Februar 2022 14:36:30 CET Thomas Huth wrote:
> > > For lines less than 90 characters, it's just a warning, and I think it's
> > > ok
> > > in such cases to keep it longer than 80 characters, if the result of
> > > breaking it up would look more awkward otherwise.
> > >
> > > Thomas
> >
> > This doesn't look awkward to me:
> > error_report_once(
> >
> > "pthread_fchdir_np() is not available on this version of
> > macOS"
> >
> > );
>
> I think that looks pretty strange, though "git grep -A3 -- '($'" does show
> other examples of doing it that way. I'd favour leaving it as a single
> line, which the style guide allows ("better to have an 85 character line
> than one which is awkwardly wrapped").
>
> Personally I would favour just not warning at all about the more-than-80
> less-than-90 lines case: it mostly tends to produce discussions like this
> one and people preferring to break lines that would be better unbroken.
> I know not everybody agrees with that, though.
>
> -- PMM
There is a practical reason for keeping things <80 chars: some email clients
like mine do awkward attempts to constrain lines to 80 chars in replies, which
I then always have to manually fix for the quoted diff being readable again.
E.g. in this case it screwed it like this:
> +int qemu_mknodat(int dirfd, const char *filename, mode_t mode, dev_t dev)
> +{
> + int preserved_errno, err;
> + if (!pthread_fchdir_np) {
> + error_report_once("pthread_fchdir_np() not available on this
> version of macOS"); + return -ENOTSUP;
> + }
> + if (pthread_fchdir_np(dirfd) < 0) {
> + return -1;
> + }
Anyway, I leave this as-is then, as I seem to have a minority opinion.
Best regards,
Christian Schoenebeck
