[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
in info reader leading parentheses parsed twice for references?
From: |
Patrice Dumas |
Subject: |
in info reader leading parentheses parsed twice for references? |
Date: |
Sat, 18 Feb 2012 13:25:30 +0100 |
User-agent: |
Mutt/1.4.2.2i |
Hello,
I am reading a bit the info reader code to understand more clearly what
should be protected in which context. I stumbled on something I don't
really understand and my feeling is that there is a bug (or two).
My understanding of the calls leading to gathering all the xrefs in a node
(a similar issue with similar calls certainly arises for menu entries)
is along
info_xref_item
info_select_reference_this_line
-> info_menu_or_ref_item (.... info_xrefs_of_node)
info_xrefs_of_node -> info_xrefs -> info_references_internal(INFO_XREF_LABEL, )
In info_references_internal INFO_XREF_LABEL is found, then a following :
is searched for. If there is another :, the node name is used directly
(As a side note, I don't really understood if/how the filename is determined
in that case if the note is like *Note (file)node::).
If there is no flollowing :, the node and file names are parsed thanks to
info_parse_node.
In info_parse_node, first the (FILENAME) is determined taking into account
nested parentheses. At the end of this code, the position is set at the
last correctly nested closed parentheses (l. 109):
/* Point directly at the nodename. */
string += i;
Then node name is parsed with a skip_node_characters (in search.c) call.
But in skip_node_characters it seems that nested parentheses beginning
the string are again taken into account. Isn't there something strange
here? It seems to me that skip_node_characters should be split in two to
have a version which do not try to parse nested parentheses again. Or
maybe parsing nested parentheses is not wrong, but they should not be
parsed only if they begin the string and should a space following the
parenthesis should not be considered especially.
As said above, a potential second bug exists in case of a *Note (file)node::
cross ref, as I am not sure that the file name is taken into account.
I also don't know excactly how to test for those issues as it would require
the info reader to print somewhere the results of parsing node names and
file names of cross refs.
--
Pat
- in info reader leading parentheses parsed twice for references?,
Patrice Dumas <=