* 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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).