GNU bug report logs - #57755
29.0.50; [PATCH] Fallout 816106b

Previous Next

Full log

Message #14 received at 57755 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 57755 <at> debbugs.gnu.org, dick.r.chiang <at> gmail.com
Subject: Re: bug#57755: 29.0.50; [PATCH] Fallout 816106b
Date: Tue, 13 Sep 2022 14:56:23 +0300

> Cc: 57755 <at> debbugs.gnu.org
> Date: Tue, 13 Sep 2022 15:32:56 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> dick <dick.r.chiang <at> gmail.com> writes:
> 
> > +		   call2 (intern ("string-trim-right"), build_string (err->message),
> 
> What coding system is err->message?

That's a good question, but the same question applies to the original
code, because build_string is just a thin wrapper around make_string.

(My guess would be that the message is either US ASCII or UTF-8, given
its type in glib.  But if we want to be more defensive about that, it
should be a separate change.)

> And calling intern with a static string is IMHO an anti-pattern that
> should not be introduced further into our code.

I actually don't understand the rationale for calling
string-trim-right, not at all.  Why do we need such heavy artillery to
just remove one newline character?

As for replacing of g_clear_error with g_error_free: that's just
syntactic sugar, right?  It is not a mistake to use g_clear_error
there.  I see no reason to make such a replacement.

AFAIU, the useful part of this patch is that it avoids dereferencing
NULL.  That part should go in, but I don't think we want the rest.

Previous Next

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