GNU bug report logs - #49723
28.0.50; Test in coding.c for NUL bytes in filenames is not reliable

Previous Next

Full log

View this message in rfc822 format

From: Federico Tedin <federicotedin <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: phst <at> google.com, 49723-done <at> debbugs.gnu.org
Subject: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable
Date: Sat, 18 Sep 2021 19:57:56 +0200

[Message part 1 (text/plain, inline)]

Noted! Thank you.

Eli Zaretskii <eliz <at> gnu.org> schrieb am Sa. 18. Sept. 2021 um 08:51:

> > From: Federico Tedin <federicotedin <at> gmail.com>
> > Cc: phst <at> google.com,  49723 <at> debbugs.gnu.org
> > Date: Fri, 17 Sep 2021 21:00:08 +0200
> >
> > > Thanks.  Did you run the test suite after applying the changes, and
> > > did you see no regressions?  If you didn't yet run the test suite,
> > > please be sure to run all of it, as the use of expand-file-name is
> > > universal.
> >
> > I hadn't, so I checked out master aa59d38c59 and applied my patch on top
> > of it. I then ran "make check" and waited for a bit. There appears to be
> > only two tests failing in test/lisp/time-stamp-tests.el
> > ('time-stamp-format-day-of-week' and
> > 'time-stamp-format-string-width'). Both seem to be unrelated to my
> > change; maybe it's my system's strange combination of
> > Spanish/English/German locale-related configurations (I'm attaching the
> > log just in case). All other test files were run without problems.
>
> Thanks.  I installed your changes, and I'm therefore closing this bug.
>
> A few minor stylistic comments, for the future
>
>  . the lines in the commit log message are too wide, they should be at
>    most 66 characters, because we produce ChangeLog files from Girt
>    logs, and ChangeLog files have the fill-column set to 74, which
>    includes 9-column TAB (perhaps this means the fill-column setting
>    in .dire-locals.el should be amended?)
>  . please quote symbols in commit log messages rather than leaving
>    them unquoted (this doesn't apply to symbols in parentheses that
>    state the functions which were changed)
>  . please try to establish whether the changes need to be described in
>    the manual(s), and mark the NEWS entries accordingly (if you decide
>    there's a need to describe in the manual, please also include a
>    suitable change for that)
>
> Thanks again for working on this.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.