all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#44724: Uninitialised variables in syntax.c cause trouble.
@ 2020-11-18 17:38 Alan Mackenzie
  2020-11-18 17:57 ` martin rudalics
  0 siblings, 1 reply; 6+ messages in thread
From: Alan Mackenzie @ 2020-11-18 17:38 UTC (permalink / raw)
  To: 44724

Hello, Emacs.

On the master branch.

In src/syntax.c, there are several uninitialised static variables, one of
which is find_start_value.

It is used in function find_defun_start before being initialised.  The
first use is at L.14 of the function, this:

      && pos >= find_start_value

.  This has the effect of causing a certain (forward-comment -1) (which
calls back_comment, which calls find_defun_start) to fail.

In my test setup (I am writing tests for syntax.c), find_start_value's
value at loading time was randomly 1270, which was spuriously inside the
comment I was trying to scan backwards over.  back_comment thus failed to
recognise the comment, and returned failed.

All these variables need initialising to something if the code in
syntax.c is to work properly.

-- 
Alan Mackenzie (Nuremberg, Germany).





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

* bug#44724: Uninitialised variables in syntax.c cause trouble.
  2020-11-18 17:38 bug#44724: Uninitialised variables in syntax.c cause trouble Alan Mackenzie
@ 2020-11-18 17:57 ` martin rudalics
  2020-11-18 20:26   ` Alan Mackenzie
  0 siblings, 1 reply; 6+ messages in thread
From: martin rudalics @ 2020-11-18 17:57 UTC (permalink / raw)
  To: Alan Mackenzie, 44724

 > In src/syntax.c, there are several uninitialised static variables, one of
 > which is find_start_value.
 >
 > It is used in function find_defun_start before being initialised.  The
 > first use is at L.14 of the function, this:
 >
 >        && pos >= find_start_value
 >
 > .  This has the effect of causing a certain (forward-comment -1) (which
 > calls back_comment, which calls find_defun_start) to fail.
 >
 > In my test setup (I am writing tests for syntax.c), find_start_value's
 > value at loading time was randomly 1270, which was spuriously inside the
 > comment I was trying to scan backwards over.  back_comment thus failed to
 > recognise the comment, and returned failed.

Just curious: Did current_buffer == find_start_buffer really succeed
in your scenario?

martin





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

* bug#44724: Uninitialised variables in syntax.c cause trouble.
  2020-11-18 17:57 ` martin rudalics
@ 2020-11-18 20:26   ` Alan Mackenzie
  2020-11-19  8:25     ` martin rudalics
  0 siblings, 1 reply; 6+ messages in thread
From: Alan Mackenzie @ 2020-11-18 20:26 UTC (permalink / raw)
  To: martin rudalics; +Cc: 44724

Hello, Martin.

On Wed, Nov 18, 2020 at 18:57:37 +0100, martin rudalics wrote:
>  > In src/syntax.c, there are several uninitialised static variables, one of
>  > which is find_start_value.

>  > It is used in function find_defun_start before being initialised.  The
>  > first use is at L.14 of the function, this:

>  >        && pos >= find_start_value

>  > .  This has the effect of causing a certain (forward-comment -1) (which
>  > calls back_comment, which calls find_defun_start) to fail.

>  > In my test setup (I am writing tests for syntax.c), find_start_value's
>  > value at loading time was randomly 1270, which was spuriously inside the
>  > comment I was trying to scan backwards over.  back_comment thus failed to
>  > recognise the comment, and returned failed.

> Just curious: Did current_buffer == find_start_buffer really succeed
> in your scenario?

Yes it did.  All four comparisons in that block of code succeeded,
causing a spurious value to be returned by find_defun_start.

But now I think that that value was a previously valid one which just
hadn't been updated on buffer changes.

I don't think there's any cache invalidation code associated with this
cache, and I think that's why it gave an invalid result.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).





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

* bug#44724: Uninitialised variables in syntax.c cause trouble.
  2020-11-18 20:26   ` Alan Mackenzie
@ 2020-11-19  8:25     ` martin rudalics
  2020-11-19 16:30       ` Alan Mackenzie
  0 siblings, 1 reply; 6+ messages in thread
From: martin rudalics @ 2020-11-19  8:25 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: 44724

 >> Just curious: Did current_buffer == find_start_buffer really succeed
 >> in your scenario?
 >
 > Yes it did.  All four comparisons in that block of code succeeded,
 > causing a spurious value to be returned by find_defun_start.

Isn't the probability for such a thing to be caused by uninitialized
variables lower than that of the Emacs tagging scheme to fail as a
whole?

 > But now I think that that value was a previously valid one which just
 > hadn't been updated on buffer changes.
 >
 > I don't think there's any cache invalidation code associated with this
 > cache,

MODIFF == find_start_modiff

 > and I think that's why it gave an invalid result.

martin





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

* bug#44724: Uninitialised variables in syntax.c cause trouble.
  2020-11-19  8:25     ` martin rudalics
@ 2020-11-19 16:30       ` Alan Mackenzie
  2020-11-24  8:02         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 6+ messages in thread
From: Alan Mackenzie @ 2020-11-19 16:30 UTC (permalink / raw)
  To: martin rudalics; +Cc: 44724

Hello, Martin.

On Thu, Nov 19, 2020 at 09:25:50 +0100, martin rudalics wrote:
>  >> Just curious: Did current_buffer == find_start_buffer really succeed
>  >> in your scenario?

>  > Yes it did.  All four comparisons in that block of code succeeded,
>  > causing a spurious value to be returned by find_defun_start.

> Isn't the probability for such a thing to be caused by uninitialized
> variables lower than that of the Emacs tagging scheme to fail as a
> whole?

Yes.

>  > But now I think that that value was a previously valid one which just
>  > hadn't been updated on buffer changes.

>  > I don't think there's any cache invalidation code associated with this
>  > cache,

> MODIFF == find_start_modiff

Yes, thanks, I was wrong there.

>  > and I think that's why it gave an invalid result.

I've found out what my problem is.  find_defun_start, unless one takes
precautions against it, calls syntax-ppss, which in my situation was
uninitialised.  There is nothing in Emacs to cause the initialisation of
syntax-ppss when, say, the syntax-table is changed.  It all needs to be
done by hand.

I'll close this bug as not a bug.

Thanks for all the help!

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).





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

* bug#44724: Uninitialised variables in syntax.c cause trouble.
  2020-11-19 16:30       ` Alan Mackenzie
@ 2020-11-24  8:02         ` Lars Ingebrigtsen
  0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2020-11-24  8:02 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: 44724

Alan Mackenzie <acm@muc.de> writes:

> I'll close this bug as not a bug.

This wasn't done, so I'm doing that now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





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

end of thread, other threads:[~2020-11-24  8:02 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-11-18 17:38 bug#44724: Uninitialised variables in syntax.c cause trouble Alan Mackenzie
2020-11-18 17:57 ` martin rudalics
2020-11-18 20:26   ` Alan Mackenzie
2020-11-19  8:25     ` martin rudalics
2020-11-19 16:30       ` Alan Mackenzie
2020-11-24  8:02         ` Lars Ingebrigtsen

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.