all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#69953: [PATCH] Remove duplicated asserts and checks
@ 2024-03-23  3:27 Sergey Vinokurov
  2024-03-23  7:15 ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Sergey Vinokurov @ 2024-03-23  3:27 UTC (permalink / raw)
  To: 69953

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

Hello,

I noticed that emacs-module.c contains duplicate 
module_non_local_exit_check() checks and 
module_assert_thread/module_assert_env asserts, mostly performed at the 
same point in program sequentially.

The module_non_local_exit_check() checks happen in 
MODULE_HANDLE_NONLOCAL_EXIT and MODULE_FUNCTION_BEGIN_NO_CATCH macros. 
The MODULE_HANDLE_NONLOCAL_EXIT is never used by itself, only as part of 
MODULE_FUNCTION_BEGIN which starts with MODULE_FUNCTION_BEGIN_NO_CATCH 
that performs the check.

In addition, there're 6 "Implementation of runtime and environment 
functions" rules outlined where MODULE_HANDLE_NONLOCAL_EXIT should be 
called at step 4 but module_non_local_exit_check() is supposed to have 
already happened at step 3 so documentation does not seem to intend for 
the check to be repeated in MODULE_HANDLE_NONLOCAL_EXIT.

Regarding asserts my observation is that module_non_local_exit_check() 
already contains module_assert_thread and module_assert_env so there's 
no need to do asserts if first thing we do is call 
module_non_local_exit_check.

Regards,
Sergey

[-- Attachment #2: 0001-Remove-duplicated-asserts-and-checks.patch --]
[-- Type: text/x-patch, Size: 2592 bytes --]

From 8c8516ee4869690d0d9418b26d4fae90520c9860 Mon Sep 17 00:00:00 2001
From: Sergey Vinokurov <serg.foo@gmail.com>
Date: Sat, 23 Mar 2024 02:15:06 +0000
Subject: [PATCH] Remove duplicated asserts and checks

* src/emacs-module.c (MODULE_HANDLE_NONLOCAL_EXIT): Remove redundant check
* src/emacs-module.c (MODULE_FUNCTION_BEGIN_NO_CATCH): Remove redundant assert
* src/emacs-module.c (module_non_local_exit_signal): Remove redundant assert
* src/emacs-module.c (module_non_local_exit_throw): Remove redundant assert
---
 src/emacs-module.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/src/emacs-module.c b/src/emacs-module.c
index 08db39b0b0d..fbeeb146a68 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -264,8 +264,6 @@ module_decode_utf_8 (const char *str, ptrdiff_t len)
 /* TODO: Make backtraces work if this macro is used.  */
 
 #define MODULE_HANDLE_NONLOCAL_EXIT(retval)                             \
-  if (module_non_local_exit_check (env) != emacs_funcall_exit_return)	\
-    return retval;							\
   struct handler *internal_handler =                                    \
     push_handler_nosignal (Qt, CATCHER_ALL);                            \
   if (!internal_handler)                                                \
@@ -332,8 +330,6 @@ #define MODULE_INTERNAL_CLEANUP()		\
 
 #define MODULE_FUNCTION_BEGIN_NO_CATCH(error_retval)                    \
   do {                                                                  \
-    module_assert_thread ();                                            \
-    module_assert_env (env);                                            \
     if (module_non_local_exit_check (env) != emacs_funcall_exit_return) \
       return error_retval;                                              \
   } while (false)
@@ -523,8 +519,6 @@ module_non_local_exit_get (emacs_env *env,
 module_non_local_exit_signal (emacs_env *env,
                               emacs_value symbol, emacs_value data)
 {
-  module_assert_thread ();
-  module_assert_env (env);
   if (module_non_local_exit_check (env) == emacs_funcall_exit_return)
     module_non_local_exit_signal_1 (env, value_to_lisp (symbol),
 				    value_to_lisp (data));
@@ -533,8 +527,6 @@ module_non_local_exit_signal (emacs_env *env,
 static void
 module_non_local_exit_throw (emacs_env *env, emacs_value tag, emacs_value value)
 {
-  module_assert_thread ();
-  module_assert_env (env);
   if (module_non_local_exit_check (env) == emacs_funcall_exit_return)
     module_non_local_exit_throw_1 (env, value_to_lisp (tag),
 				   value_to_lisp (value));
-- 
2.43.1


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-03-23  3:27 bug#69953: [PATCH] Remove duplicated asserts and checks Sergey Vinokurov
@ 2024-03-23  7:15 ` Eli Zaretskii
  2024-03-23 12:38   ` Sergey Vinokurov
  2024-04-13  7:42   ` Eli Zaretskii
  0 siblings, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2024-03-23  7:15 UTC (permalink / raw)
  To: Sergey Vinokurov; +Cc: Philipp Stephani, 69953, Daniel Colascione

> Date: Sat, 23 Mar 2024 03:27:34 +0000
> From: Sergey Vinokurov <serg.foo@gmail.com>
> 
> I noticed that emacs-module.c contains duplicate 
> module_non_local_exit_check() checks and 
> module_assert_thread/module_assert_env asserts, mostly performed at the 
> same point in program sequentially.
> 
> The module_non_local_exit_check() checks happen in 
> MODULE_HANDLE_NONLOCAL_EXIT and MODULE_FUNCTION_BEGIN_NO_CATCH macros. 
> The MODULE_HANDLE_NONLOCAL_EXIT is never used by itself, only as part of 
> MODULE_FUNCTION_BEGIN which starts with MODULE_FUNCTION_BEGIN_NO_CATCH 
> that performs the check.
> 
> In addition, there're 6 "Implementation of runtime and environment 
> functions" rules outlined where MODULE_HANDLE_NONLOCAL_EXIT should be 
> called at step 4 but module_non_local_exit_check() is supposed to have 
> already happened at step 3 so documentation does not seem to intend for 
> the check to be repeated in MODULE_HANDLE_NONLOCAL_EXIT.
> 
> Regarding asserts my observation is that module_non_local_exit_check() 
> already contains module_assert_thread and module_assert_env so there's 
> no need to do asserts if first thing we do is call 
> module_non_local_exit_check.

Thanks, but why is that a problem?  module_assertions is false by
default, and the function to turn on module assertions is not even
documented in the ELisp manual.  IOW, this is a debugging aid which
will rarely if at all activated, and if it is, that's on purpose by
the programmer who is investigating some tricky problem.  Why is it a
problem to have too many assertions, which might help that programmer
find a bug?

I added Daniel and Philipp to the discussion, in case they have
comments to this proposal.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-03-23  7:15 ` Eli Zaretskii
@ 2024-03-23 12:38   ` Sergey Vinokurov
  2024-04-13  7:42   ` Eli Zaretskii
  1 sibling, 0 replies; 13+ messages in thread
From: Sergey Vinokurov @ 2024-03-23 12:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Philipp Stephani, 69953, Daniel Colascione

The issue is that the same thing is being checked just after it was 
checked. The checks I propose to remove are not going to catch any new 
errors under any possible scenario.

Even with module_assertions disabled, the assert functions are still 
called - a very minor annoyance.

On 23/03/2024 07:15, Eli Zaretskii wrote:
>> Date: Sat, 23 Mar 2024 03:27:34 +0000
>> From: Sergey Vinokurov <serg.foo@gmail.com>
>>
>> I noticed that emacs-module.c contains duplicate
>> module_non_local_exit_check() checks and
>> module_assert_thread/module_assert_env asserts, mostly performed at the
>> same point in program sequentially.
>>
>> The module_non_local_exit_check() checks happen in
>> MODULE_HANDLE_NONLOCAL_EXIT and MODULE_FUNCTION_BEGIN_NO_CATCH macros.
>> The MODULE_HANDLE_NONLOCAL_EXIT is never used by itself, only as part of
>> MODULE_FUNCTION_BEGIN which starts with MODULE_FUNCTION_BEGIN_NO_CATCH
>> that performs the check.
>>
>> In addition, there're 6 "Implementation of runtime and environment
>> functions" rules outlined where MODULE_HANDLE_NONLOCAL_EXIT should be
>> called at step 4 but module_non_local_exit_check() is supposed to have
>> already happened at step 3 so documentation does not seem to intend for
>> the check to be repeated in MODULE_HANDLE_NONLOCAL_EXIT.
>>
>> Regarding asserts my observation is that module_non_local_exit_check()
>> already contains module_assert_thread and module_assert_env so there's
>> no need to do asserts if first thing we do is call
>> module_non_local_exit_check.
> 
> Thanks, but why is that a problem?  module_assertions is false by
> default, and the function to turn on module assertions is not even
> documented in the ELisp manual.  IOW, this is a debugging aid which
> will rarely if at all activated, and if it is, that's on purpose by
> the programmer who is investigating some tricky problem.  Why is it a
> problem to have too many assertions, which might help that programmer
> find a bug?
> 
> I added Daniel and Philipp to the discussion, in case they have
> comments to this proposal.






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-03-23  7:15 ` Eli Zaretskii
  2024-03-23 12:38   ` Sergey Vinokurov
@ 2024-04-13  7:42   ` Eli Zaretskii
  2024-04-27  8:27     ` Eli Zaretskii
  1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2024-04-13  7:42 UTC (permalink / raw)
  To: phst, dancol; +Cc: serg.foo, 69953

Ping! Philipp and Daniel, do you have any comments on this?

> Cc: Philipp Stephani <phst@google.com>, 69953@debbugs.gnu.org,
>  Daniel Colascione <dancol@dancol.org>
> Date: Sat, 23 Mar 2024 09:15:04 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 23 Mar 2024 03:27:34 +0000
> > From: Sergey Vinokurov <serg.foo@gmail.com>
> > 
> > I noticed that emacs-module.c contains duplicate 
> > module_non_local_exit_check() checks and 
> > module_assert_thread/module_assert_env asserts, mostly performed at the 
> > same point in program sequentially.
> > 
> > The module_non_local_exit_check() checks happen in 
> > MODULE_HANDLE_NONLOCAL_EXIT and MODULE_FUNCTION_BEGIN_NO_CATCH macros. 
> > The MODULE_HANDLE_NONLOCAL_EXIT is never used by itself, only as part of 
> > MODULE_FUNCTION_BEGIN which starts with MODULE_FUNCTION_BEGIN_NO_CATCH 
> > that performs the check.
> > 
> > In addition, there're 6 "Implementation of runtime and environment 
> > functions" rules outlined where MODULE_HANDLE_NONLOCAL_EXIT should be 
> > called at step 4 but module_non_local_exit_check() is supposed to have 
> > already happened at step 3 so documentation does not seem to intend for 
> > the check to be repeated in MODULE_HANDLE_NONLOCAL_EXIT.
> > 
> > Regarding asserts my observation is that module_non_local_exit_check() 
> > already contains module_assert_thread and module_assert_env so there's 
> > no need to do asserts if first thing we do is call 
> > module_non_local_exit_check.
> 
> Thanks, but why is that a problem?  module_assertions is false by
> default, and the function to turn on module assertions is not even
> documented in the ELisp manual.  IOW, this is a debugging aid which
> will rarely if at all activated, and if it is, that's on purpose by
> the programmer who is investigating some tricky problem.  Why is it a
> problem to have too many assertions, which might help that programmer
> find a bug?
> 
> I added Daniel and Philipp to the discussion, in case they have
> comments to this proposal.
> 
> 
> 
> 





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-04-13  7:42   ` Eli Zaretskii
@ 2024-04-27  8:27     ` Eli Zaretskii
  2024-05-09  7:24       ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2024-04-27  8:27 UTC (permalink / raw)
  To: Philipp Stephani, dancol; +Cc: serg.foo, 69953

Ping! Ping!  Philipp and Daniel, any comments?

> Cc: serg.foo@gmail.com, 69953@debbugs.gnu.org
> Date: Sat, 13 Apr 2024 10:42:50 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Ping! Philipp and Daniel, do you have any comments on this?
> 
> > Cc: Philipp Stephani <phst@google.com>, 69953@debbugs.gnu.org,
> >  Daniel Colascione <dancol@dancol.org>
> > Date: Sat, 23 Mar 2024 09:15:04 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > Date: Sat, 23 Mar 2024 03:27:34 +0000
> > > From: Sergey Vinokurov <serg.foo@gmail.com>
> > > 
> > > I noticed that emacs-module.c contains duplicate 
> > > module_non_local_exit_check() checks and 
> > > module_assert_thread/module_assert_env asserts, mostly performed at the 
> > > same point in program sequentially.
> > > 
> > > The module_non_local_exit_check() checks happen in 
> > > MODULE_HANDLE_NONLOCAL_EXIT and MODULE_FUNCTION_BEGIN_NO_CATCH macros. 
> > > The MODULE_HANDLE_NONLOCAL_EXIT is never used by itself, only as part of 
> > > MODULE_FUNCTION_BEGIN which starts with MODULE_FUNCTION_BEGIN_NO_CATCH 
> > > that performs the check.
> > > 
> > > In addition, there're 6 "Implementation of runtime and environment 
> > > functions" rules outlined where MODULE_HANDLE_NONLOCAL_EXIT should be 
> > > called at step 4 but module_non_local_exit_check() is supposed to have 
> > > already happened at step 3 so documentation does not seem to intend for 
> > > the check to be repeated in MODULE_HANDLE_NONLOCAL_EXIT.
> > > 
> > > Regarding asserts my observation is that module_non_local_exit_check() 
> > > already contains module_assert_thread and module_assert_env so there's 
> > > no need to do asserts if first thing we do is call 
> > > module_non_local_exit_check.
> > 
> > Thanks, but why is that a problem?  module_assertions is false by
> > default, and the function to turn on module assertions is not even
> > documented in the ELisp manual.  IOW, this is a debugging aid which
> > will rarely if at all activated, and if it is, that's on purpose by
> > the programmer who is investigating some tricky problem.  Why is it a
> > problem to have too many assertions, which might help that programmer
> > find a bug?
> > 
> > I added Daniel and Philipp to the discussion, in case they have
> > comments to this proposal.
> > 
> > 
> > 
> > 
> 
> 
> 
> 





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-04-27  8:27     ` Eli Zaretskii
@ 2024-05-09  7:24       ` Eli Zaretskii
  2024-05-09 14:16         ` Sergey Vinokurov
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2024-05-09  7:24 UTC (permalink / raw)
  To: p.stephani2, dancol, serg.foo; +Cc: 69953

tags 69953 wontfix
close 69953
thanks

> Cc: serg.foo@gmail.com, 69953@debbugs.gnu.org
> Date: Sat, 27 Apr 2024 11:27:41 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Ping! Ping!  Philipp and Daniel, any comments?
> 
> > Cc: serg.foo@gmail.com, 69953@debbugs.gnu.org
> > Date: Sat, 13 Apr 2024 10:42:50 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > Ping! Philipp and Daniel, do you have any comments on this?
> > 
> > > Cc: Philipp Stephani <phst@google.com>, 69953@debbugs.gnu.org,
> > >  Daniel Colascione <dancol@dancol.org>
> > > Date: Sat, 23 Mar 2024 09:15:04 +0200
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > 
> > > > Date: Sat, 23 Mar 2024 03:27:34 +0000
> > > > From: Sergey Vinokurov <serg.foo@gmail.com>
> > > > 
> > > > I noticed that emacs-module.c contains duplicate 
> > > > module_non_local_exit_check() checks and 
> > > > module_assert_thread/module_assert_env asserts, mostly performed at the 
> > > > same point in program sequentially.
> > > > 
> > > > The module_non_local_exit_check() checks happen in 
> > > > MODULE_HANDLE_NONLOCAL_EXIT and MODULE_FUNCTION_BEGIN_NO_CATCH macros. 
> > > > The MODULE_HANDLE_NONLOCAL_EXIT is never used by itself, only as part of 
> > > > MODULE_FUNCTION_BEGIN which starts with MODULE_FUNCTION_BEGIN_NO_CATCH 
> > > > that performs the check.
> > > > 
> > > > In addition, there're 6 "Implementation of runtime and environment 
> > > > functions" rules outlined where MODULE_HANDLE_NONLOCAL_EXIT should be 
> > > > called at step 4 but module_non_local_exit_check() is supposed to have 
> > > > already happened at step 3 so documentation does not seem to intend for 
> > > > the check to be repeated in MODULE_HANDLE_NONLOCAL_EXIT.
> > > > 
> > > > Regarding asserts my observation is that module_non_local_exit_check() 
> > > > already contains module_assert_thread and module_assert_env so there's 
> > > > no need to do asserts if first thing we do is call 
> > > > module_non_local_exit_check.
> > > 
> > > Thanks, but why is that a problem?  module_assertions is false by
> > > default, and the function to turn on module assertions is not even
> > > documented in the ELisp manual.  IOW, this is a debugging aid which
> > > will rarely if at all activated, and if it is, that's on purpose by
> > > the programmer who is investigating some tricky problem.  Why is it a
> > > problem to have too many assertions, which might help that programmer
> > > find a bug?
> > > 
> > > I added Daniel and Philipp to the discussion, in case they have
> > > comments to this proposal.

Given the lack of comments, I conclude that there's no interest in
installing this, and I'm therefore closing this bug.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-05-09  7:24       ` Eli Zaretskii
@ 2024-05-09 14:16         ` Sergey Vinokurov
  2024-05-11 10:02           ` Eli Zaretskii
  2024-05-11 13:11           ` Daniel Colascione
  0 siblings, 2 replies; 13+ messages in thread
From: Sergey Vinokurov @ 2024-05-09 14:16 UTC (permalink / raw)
  To: Eli Zaretskii, p.stephani2, dancol; +Cc: 69953

On 09/05/2024 08:24, Eli Zaretskii wrote:
> tags 69953 wontfix
> close 69953
> thanks
> 
>> Cc: serg.foo@gmail.com, 69953@debbugs.gnu.org
>> Date: Sat, 27 Apr 2024 11:27:41 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>>
>> Ping! Ping!  Philipp and Daniel, any comments?
>>
>>> Cc: serg.foo@gmail.com, 69953@debbugs.gnu.org
>>> Date: Sat, 13 Apr 2024 10:42:50 +0300
>>> From: Eli Zaretskii <eliz@gnu.org>
>>>
>>> Ping! Philipp and Daniel, do you have any comments on this?
>>>
>>>> Cc: Philipp Stephani <phst@google.com>, 69953@debbugs.gnu.org,
>>>>   Daniel Colascione <dancol@dancol.org>
>>>> Date: Sat, 23 Mar 2024 09:15:04 +0200
>>>> From: Eli Zaretskii <eliz@gnu.org>
>>>>
>>>>> Date: Sat, 23 Mar 2024 03:27:34 +0000
>>>>> From: Sergey Vinokurov <serg.foo@gmail.com>
>>>>>
>>>>> I noticed that emacs-module.c contains duplicate
>>>>> module_non_local_exit_check() checks and
>>>>> module_assert_thread/module_assert_env asserts, mostly performed at the
>>>>> same point in program sequentially.
>>>>>
>>>>> The module_non_local_exit_check() checks happen in
>>>>> MODULE_HANDLE_NONLOCAL_EXIT and MODULE_FUNCTION_BEGIN_NO_CATCH macros.
>>>>> The MODULE_HANDLE_NONLOCAL_EXIT is never used by itself, only as part of
>>>>> MODULE_FUNCTION_BEGIN which starts with MODULE_FUNCTION_BEGIN_NO_CATCH
>>>>> that performs the check.
>>>>>
>>>>> In addition, there're 6 "Implementation of runtime and environment
>>>>> functions" rules outlined where MODULE_HANDLE_NONLOCAL_EXIT should be
>>>>> called at step 4 but module_non_local_exit_check() is supposed to have
>>>>> already happened at step 3 so documentation does not seem to intend for
>>>>> the check to be repeated in MODULE_HANDLE_NONLOCAL_EXIT.
>>>>>
>>>>> Regarding asserts my observation is that module_non_local_exit_check()
>>>>> already contains module_assert_thread and module_assert_env so there's
>>>>> no need to do asserts if first thing we do is call
>>>>> module_non_local_exit_check.
>>>>
>>>> Thanks, but why is that a problem?  module_assertions is false by
>>>> default, and the function to turn on module assertions is not even
>>>> documented in the ELisp manual.  IOW, this is a debugging aid which
>>>> will rarely if at all activated, and if it is, that's on purpose by
>>>> the programmer who is investigating some tricky problem.  Why is it a
>>>> problem to have too many assertions, which might help that programmer
>>>> find a bug?
>>>>
>>>> I added Daniel and Philipp to the discussion, in case they have
>>>> comments to this proposal.
> 
> Given the lack of comments, I conclude that there's no interest in
> installing this, and I'm therefore closing this bug.

I'm interested to get this installed - can I do anything to facilitate?





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-05-09 14:16         ` Sergey Vinokurov
@ 2024-05-11 10:02           ` Eli Zaretskii
  2024-05-11 12:12             ` Sergey Vinokurov
  2024-05-11 13:11           ` Daniel Colascione
  1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2024-05-11 10:02 UTC (permalink / raw)
  To: Sergey Vinokurov; +Cc: p.stephani2, dancol, 69953

> Date: Thu, 9 May 2024 15:16:05 +0100
> Cc: 69953@debbugs.gnu.org
> From: Sergey Vinokurov <serg.foo@gmail.com>
> 
> >>>> I added Daniel and Philipp to the discussion, in case they have
> >>>> comments to this proposal.
> > 
> > Given the lack of comments, I conclude that there's no interest in
> > installing this, and I'm therefore closing this bug.
> 
> I'm interested to get this installed - can I do anything to facilitate?

Given the lack of responses, I doubt that.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-05-11 10:02           ` Eli Zaretskii
@ 2024-05-11 12:12             ` Sergey Vinokurov
  2024-05-11 12:18               ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Sergey Vinokurov @ 2024-05-11 12:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: p.stephani2, dancol, 69953

On 11/05/2024 11:02, Eli Zaretskii wrote:
>> Date: Thu, 9 May 2024 15:16:05 +0100
>> Cc: 69953@debbugs.gnu.org
>> From: Sergey Vinokurov <serg.foo@gmail.com>
>>
>>>>>> I added Daniel and Philipp to the discussion, in case they have
>>>>>> comments to this proposal.
>>>
>>> Given the lack of comments, I conclude that there's no interest in
>>> installing this, and I'm therefore closing this bug.
>>
>> I'm interested to get this installed - can I do anything to facilitate?
> 
> Given the lack of responses, I doubt that.

Is there no way to reevaluate the patch from the start? It's fairly 
small, perhaps I did poor job explaining why it's good idea?





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-05-11 12:12             ` Sergey Vinokurov
@ 2024-05-11 12:18               ` Eli Zaretskii
  2024-05-11 12:57                 ` Sergey Vinokurov
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2024-05-11 12:18 UTC (permalink / raw)
  To: Sergey Vinokurov; +Cc: p.stephani2, dancol, 69953

> Date: Sat, 11 May 2024 13:12:33 +0100
> Cc: p.stephani2@gmail.com, dancol@dancol.org, 69953@debbugs.gnu.org
> From: Sergey Vinokurov <serg.foo@gmail.com>
> 
> On 11/05/2024 11:02, Eli Zaretskii wrote:
> >> Date: Thu, 9 May 2024 15:16:05 +0100
> >> Cc: 69953@debbugs.gnu.org
> >> From: Sergey Vinokurov <serg.foo@gmail.com>
> >>
> >>>>>> I added Daniel and Philipp to the discussion, in case they have
> >>>>>> comments to this proposal.
> >>>
> >>> Given the lack of comments, I conclude that there's no interest in
> >>> installing this, and I'm therefore closing this bug.
> >>
> >> I'm interested to get this installed - can I do anything to facilitate?
> > 
> > Given the lack of responses, I doubt that.
> 
> Is there no way to reevaluate the patch from the start? It's fairly 
> small, perhaps I did poor job explaining why it's good idea?

AFAIU, the code isn't wrong, and doesn't cause any problems.  You just
think it's redundant.  That's a judgment call, and without Daniel and
Philipp, who worked on most of this case, assessing the proposal, I
don't want to change code that worked well for us for several Emacs
releases, just because it might be redundant.

Why are you so eager to install these changes?





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-05-11 12:18               ` Eli Zaretskii
@ 2024-05-11 12:57                 ` Sergey Vinokurov
  2024-05-11 13:05                   ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Sergey Vinokurov @ 2024-05-11 12:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: p.stephani2, dancol, 69953

On 11/05/2024 13:18, Eli Zaretskii wrote:
>> Date: Sat, 11 May 2024 13:12:33 +0100
>> Cc: p.stephani2@gmail.com, dancol@dancol.org, 69953@debbugs.gnu.org
>> From: Sergey Vinokurov <serg.foo@gmail.com>
>>
>>> Given the lack of responses, I doubt that.
>>
>> Is there no way to reevaluate the patch from the start? It's fairly
>> small, perhaps I did poor job explaining why it's good idea?
> 
> AFAIU, the code isn't wrong, and doesn't cause any problems.  You just
> think it's redundant.  That's a judgment call, and without Daniel and
> Philipp, who worked on most of this case, assessing the proposal, I
> don't want to change code that worked well for us for several Emacs
> releases, just because it might be redundant.
> 
> Why are you so eager to install these changes?

As I benefit from Emacs daily I want to help make it the best version of 
itself. Many things in Emacs I rely on were made by someone, I thought 
this change would ever so slightly benefit others.

It's small indeed and maybe even inconsequential. But as the saying 
goes, the devil is in the details - the small things. Another reason to 
bother is to see whether I can manage to get small things merged - 
bigger contributions would likely involve all the hard parts of merging 
small contributions and then some. If I'm not able to finish small 
things then bigger ones are unlikely to succeed.

As for judgement call I don't know, I mostly unwrapped the various macro 
calls and saw that what one ends up with is assert after assert of the 
same property (e.g. that current thread is OK). For example, if in plain 
C within Emacs, in some other module one found

Lisp_Object
foo(Lisp_Object arg)
   {
     ...
     eassert(NILP(arg));
     eassert(NILP(arg));
     ...
   }

then it would surely be desirable to keep only one call to eassert as 
the second one serves no purpose and provides no extra checks. I argue 
that my patch does exactly that, the only complication is that some 
assert calls come from macro definitions which need to be unwrapped to 
see what's going on.

To paraphrase the example, I removed the second call to assert while 
keeping the first one so same checks happen in the same places as before.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-05-11 12:57                 ` Sergey Vinokurov
@ 2024-05-11 13:05                   ` Eli Zaretskii
  0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2024-05-11 13:05 UTC (permalink / raw)
  To: Sergey Vinokurov; +Cc: p.stephani2, dancol, 69953

> Date: Sat, 11 May 2024 13:57:31 +0100
> Cc: p.stephani2@gmail.com, dancol@dancol.org, 69953@debbugs.gnu.org
> From: Sergey Vinokurov <serg.foo@gmail.com>
> 
> It's small indeed and maybe even inconsequential. But as the saying 
> goes, the devil is in the details - the small things. Another reason to 
> bother is to see whether I can manage to get small things merged - 
> bigger contributions would likely involve all the hard parts of merging 
> small contributions and then some. If I'm not able to finish small 
> things then bigger ones are unlikely to succeed.

I'm sure you will find a lot of other opportunities for small
contributions, no need to extrapolate from this one.

In many places in Emacs, there's more to the code than meets the eye,
so bitter experience taught me to be extremely cautious with code I'm
not familiar enough.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#69953: [PATCH] Remove duplicated asserts and checks
  2024-05-09 14:16         ` Sergey Vinokurov
  2024-05-11 10:02           ` Eli Zaretskii
@ 2024-05-11 13:11           ` Daniel Colascione
  1 sibling, 0 replies; 13+ messages in thread
From: Daniel Colascione @ 2024-05-11 13:11 UTC (permalink / raw)
  To: Sergey Vinokurov; +Cc: Eli Zaretskii, 69953, p.stephani2

Sergey Vinokurov <serg.foo@gmail.com> writes:

> On 09/05/2024 08:24, Eli Zaretskii wrote:
>> tags 69953 wontfix
>> close 69953
>> thanks
>> 
>>> Cc: serg.foo@gmail.com, 69953@debbugs.gnu.org
>>> Date: Sat, 27 Apr 2024 11:27:41 +0300
>>> From: Eli Zaretskii <eliz@gnu.org>
>>>
>>> Ping! Ping!  Philipp and Daniel, any comments?
>>>
>>>> Cc: serg.foo@gmail.com, 69953@debbugs.gnu.org
>>>> Date: Sat, 13 Apr 2024 10:42:50 +0300
>>>> From: Eli Zaretskii <eliz@gnu.org>
>>>>
>>>> Ping! Philipp and Daniel, do you have any comments on this?
>>>>
>>>>> Cc: Philipp Stephani <phst@google.com>, 69953@debbugs.gnu.org,
>>>>>   Daniel Colascione <dancol@dancol.org>
>>>>> Date: Sat, 23 Mar 2024 09:15:04 +0200
>>>>> From: Eli Zaretskii <eliz@gnu.org>
>>>>>
>>>>>> Date: Sat, 23 Mar 2024 03:27:34 +0000
>>>>>> From: Sergey Vinokurov <serg.foo@gmail.com>
>>>>>>
>>>>>> I noticed that emacs-module.c contains duplicate
>>>>>> module_non_local_exit_check() checks and
>>>>>> module_assert_thread/module_assert_env asserts, mostly performed at the
>>>>>> same point in program sequentially.
>>>>>>
>>>>>> The module_non_local_exit_check() checks happen in
>>>>>> MODULE_HANDLE_NONLOCAL_EXIT and MODULE_FUNCTION_BEGIN_NO_CATCH macros.
>>>>>> The MODULE_HANDLE_NONLOCAL_EXIT is never used by itself, only as part of
>>>>>> MODULE_FUNCTION_BEGIN which starts with MODULE_FUNCTION_BEGIN_NO_CATCH
>>>>>> that performs the check.
>>>>>>
>>>>>> In addition, there're 6 "Implementation of runtime and environment
>>>>>> functions" rules outlined where MODULE_HANDLE_NONLOCAL_EXIT should be
>>>>>> called at step 4 but module_non_local_exit_check() is supposed to have
>>>>>> already happened at step 3 so documentation does not seem to intend for
>>>>>> the check to be repeated in MODULE_HANDLE_NONLOCAL_EXIT.
>>>>>>
>>>>>> Regarding asserts my observation is that module_non_local_exit_check()
>>>>>> already contains module_assert_thread and module_assert_env so there's
>>>>>> no need to do asserts if first thing we do is call
>>>>>> module_non_local_exit_check.
>>>>>
>>>>> Thanks, but why is that a problem?  module_assertions is false by
>>>>> default, and the function to turn on module assertions is not even
>>>>> documented in the ELisp manual.  IOW, this is a debugging aid which
>>>>> will rarely if at all activated, and if it is, that's on purpose by
>>>>> the programmer who is investigating some tricky problem.  Why is it a
>>>>> problem to have too many assertions, which might help that programmer
>>>>> find a bug?
>>>>>
>>>>> I added Daniel and Philipp to the discussion, in case they have
>>>>> comments to this proposal.
>> Given the lack of comments, I conclude that there's no interest in
>> installing this, and I'm therefore closing this bug.
>
> I'm interested to get this installed - can I do anything to facilitate?


Programming is not an exercise in Huffman compression :-).  Sometimes,
things that look repetitive are not duplicative: the same text can express
different things in different contexts.  The assertions in this patch
express the intent of the authors of macros like
MODULE_FUNCTION_BEGIN_NO_CATCH.  Their presence in the code signifies
in writing the contract to which users of MODULE_FUNCTION_BEGIN_NO_CATCH
and other facilities must adhere.  Deleting them would therefore make it
incrementally harder to understand the code, as it costs the brain more
to infer a contract than to read one.

I definitely appreciate the desire to clean up the codebase.  I think
the energy that's gone into this thread could be more productively
applied to other code cleanups.





^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2024-05-11 13:11 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-23  3:27 bug#69953: [PATCH] Remove duplicated asserts and checks Sergey Vinokurov
2024-03-23  7:15 ` Eli Zaretskii
2024-03-23 12:38   ` Sergey Vinokurov
2024-04-13  7:42   ` Eli Zaretskii
2024-04-27  8:27     ` Eli Zaretskii
2024-05-09  7:24       ` Eli Zaretskii
2024-05-09 14:16         ` Sergey Vinokurov
2024-05-11 10:02           ` Eli Zaretskii
2024-05-11 12:12             ` Sergey Vinokurov
2024-05-11 12:18               ` Eli Zaretskii
2024-05-11 12:57                 ` Sergey Vinokurov
2024-05-11 13:05                   ` Eli Zaretskii
2024-05-11 13:11           ` Daniel Colascione

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.