osdir.com
mailing list archive
Mozy Online Backup: 2GB Free. Automatic. Secure.

Subject: [ tidy-Bugs-1331849 ] Closing Tag ignored when Start is implied/inferred - msg#00097

List: web.html-tidy.tracker

Date: Prev Next Index Thread: Prev Next Index
Bugs item #1331849, was opened at 2005-10-19 09:06
Message generated for change (Comment added) made by cmwoods
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=390963&aid=1331849&group_id=27659

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTML/XML/XHTML Parser
Group: Current - all platforms
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher M. Woods (cmwoods)
Assigned to: Nobody/Anonymous (nobody)
Summary: Closing Tag ignored when Start is implied/inferred

Initial Comment:
It appears that Tidy is ignoring the closing tag when
the opening/start tag is implied when using the HASH
lookup functionality (ELEMENT_HASH_LOOKUP). A trace
into the code shows that:

- when creating a new tag from a token in the input
stream, Tidy calls lookup() [in tags.c] which will
check the Hash Table and return the item.

- when creating an implied/inferred tag, Tidy calls
LookupTagDef() [in tags.c] which does NOT check the
Hash Table (nor the custom tags table) - only the
original def table.

When Tidy encounters the closing tag for the element
(e.g. for table close in ParseTable() [in parser.c]),
it does a check to see if the tag pointers are the same
(not the contents of the pointers). This comparison
fails because one of the pointers is from the original
def table and the other is from the hash table.

I see two options to address this:

1) Change all the pointer comparisons to key/unique
fields in the tag def structure.

2) Add the hash lookup functionality to LookupTagDef():

#ifdef ELEMENT_HASH_LOOKUP
/* this breaks if declared elements get changed
between two */
/* parser runs since Tidy would use the cached
version rather */
/* than the new one
*/
for (np = tags->hashtab[hash(s)]; np != NULL; np =
np->next)
if (tmbstrcmp(s, np->name) == 0)
return np;

for (np = tag_defs + 1; np < tag_defs +
N_TIDY_TAGS; ++np)
if (tmbstrcmp(s, np->name) == 0)
return install(tags, np);

#else

for (np = tag_defs + 1; np < tag_defs +
N_TIDY_TAGS; ++np )
if (np->id == tid)
return np;

#endif /* ELEMENT_HASH_LOOKUP */

(Note: I did not include the declared tags list in this
functional change but it probably should be included
for consistency.)

----------------------------------------------------------------------

>Comment By: Christopher M. Woods (cmwoods)
Date: 2005-10-19 13:59

Message:
Logged In: YES
user_id=576763

I must appologize here - I just C/C/P and grabbed the wrong
snippet of code when I pasted my suggest code change. What
I pasted does not compile but it is conceptually what needs
to change.

If the Hash functionality is being used then it must be used
in this function as well so that the pointer comparisons
used throughout the code function as originally intended.

I will try to update with a corrected code change suggestion
once I look into the code some more and determine how to get
a clean reference to the hash table.



----------------------------------------------------------------------

Comment By: Christopher M. Woods (cmwoods)
Date: 2005-10-19 13:25

Message:
Logged In: YES
user_id=576763

I should add to my last comment that this issue is not
experienced with the new hash lookup functionality disabled
- as both functions then return pointers from the tag def table.

It manifests specifically because pointer comparisons are
occurring and the hash table functionality creates a copy of
the tag def - the pointers are different but the content is
the same. This could be addressed by changing the hash
logic to add an extra layer of indirection (a pointer
instead of a copy) or by something similar to the change I
specified in the original issue report.

----------------------------------------------------------------------

Comment By: Christopher M. Woods (cmwoods)
Date: 2005-10-19 13:19

Message:
Logged In: YES
user_id=576763

"When Tidy encounters the closing tag for the element
(e.g. for table close in ParseTable() [in parser.c]),
it does a check to see if the tag pointers are the same
(not the contents of the pointers). This comparison
fails because one of the pointers is from the original
def table and the other is from the hash table."

This means that if an inferred table is started, it does not
exit when </table> is encountered.

Using the sample file Tidy generates:
line 6 column 1 - Warning: <tr> isn't allowed in <body> elements
line 9 column 1 - Warning: inserting implicit <table>
line 25 column 1 - Warning: discarding unexpected </table>
line 9 column 1 - Warning: plain text isn't allowed in
<table> elements
line 29 column 1 - Warning: missing <tr>
line 29 column 1 - Warning: discarding unexpected <table>
line 29 column 1 - Warning: <tr> isn't allowed in <tr> elements
line 37 column 1 - Warning: discarding unexpected </tr>
line 29 column 1 - Warning: <tr> isn't allowed in <tr> elements
line 45 column 1 - Warning: discarding unexpected </tr>
line 46 column 1 - Warning: discarding unexpected </table>
line 9 column 1 - Warning: plain text isn't allowed in
<table> elements
line 9 column 1 - Warning: missing </table> before </body>
line 9 column 1 - Warning: <table> lacks "summary" attribute

The output is incorrectly ordered and the two tables are
merged into one (see input vs. output in browser).

----------------------------------------------------------------------

Comment By: Björn Höhrmann (hoehrmann)
Date: 2005-10-19 09:18

Message:
Logged In: YES
user_id=188003

Which kind of problem does this cause?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=390963&aid=1331849&group_id=27659


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl


Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

[ tidy-Bugs-1324100 ] fix Transitional doctype

Bugs item #1324100, was opened at 2005-10-11 20:37 Message generated for change (Comment added) made by hoehrmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390963&aid=1324100&group_id=27659 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: HTML/XML/XHTML Parser Group: Current - all platforms Status: Open Resolution: None Priority: 6 Submitted By: reisio (reisio) Assigned to: Nobody/Anonymous (nobody) Summary: fix Transitional doctype Initial Comment: Is there any particular reason the transitional doctype declaration being used is one known to trigger quirks mode in all popular browsers? If not, do please change it to this: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> http://www.w3.org/QA/2002/04/valid-dtd-list.html ---------------------------------------------------------------------- >Comment By: Björn Höhrmann (hoehrmann) Date: 2005-10-19 20:12 Message: Logged In: YES user_id=188003 How does not changing the doctype such that a different processing mode is used for the result than for the input by some user agents make the document less W3C compliant or work less in most browsers? ---------------------------------------------------------------------- Comment By: reisio (reisio) Date: 2005-10-19 19:14 Message: Logged In: YES user_id=1360152 Then maybe you should change this part of the man page: "Tidy..strives to produce visually equivalent markup that is both W3C compliant and works on most browsers." ---------------------------------------------------------------------- Comment By: Björn Höhrmann (hoehrmann) Date: 2005-10-19 15:42 Message: Logged In: YES user_id=188003 We discussed doctype configuration options on the tidy- develop mailing list, I'd suggest people revive the discussion. The default behavior is to maintain the original doctype to the extend possible, which ensures that the result document will be processed with the same mode as the input document. I don't think Tidy should enforce some kind of "standards" mode by default; we already do that for XHTML documents (where the system identifier is mandatory) and do get regular bug reports from people where the result document renders differently than the input document, and our users don't understand why. ---------------------------------------------------------------------- Comment By: Jelks Cabaniss (jelks) Date: 2005-10-19 14:30 Message: Logged In: YES user_id=587974 There are two answers to that. First, the original decision to use a DOCTYPE declaration to determine CSS behavior was a huge mistake, and has caused endless amounts of grief. It's like having what gear your car is in determining the car's color. Secondly -- and this is indeed Tidy's problem -- there is no way of specifying a SYSTEM URL in the DOCTYPE declaration. We have an overloaded "doctype" option that takes one of five (currently) options -- defaulting to "auto" -- or the desired Formal Public Identifier. No way to set the System Identifier. This has been a long-standing problem. I think this should be addressed. Not just to "fix" this quirksmode silliness, but to allow XHTML 1.1 or custom Doctypes. A `doctype-system` option should do the trick, I would think. If specified, Tidy would add it to the Doctype declaration (or overwrite it if one were already in use, as in the case of XHTML 1.0 Strict or Transitional). ---------------------------------------------------------------------- Comment By: reisio (reisio) Date: 2005-10-19 10:35 Message: Logged In: YES user_id=1360152 The concern is that the URI is missing. The current doctype used will put Gecko, KHTML, Presto, Tasman, & Trident into quirks mode - just as bad as not having a doctype at all. This is (1) needless, (2) bad for the web, and (3) a thorn in the side of every person (like me) that frequents web design help forums and has to tell some newbie that the software they're using which is supposed to make their code clean and standard in fact has just wasted (quite often) many hours of their lives. The "HTML" should also of course be capitalized as a matter of conformance. ---------------------------------------------------------------------- Comment By: Björn Höhrmann (hoehrmann) Date: 2005-10-18 16:46 Message: Logged In: YES user_id=188003 Which browsers consider that significant to "quirks mode"? ---------------------------------------------------------------------- Comment By: Arnaud Desitter (arnaud02) Date: 2005-10-18 12:10 Message: Logged In: YES user_id=566665 The concern is that, for html 3.2 and 4.01, tidy insists on emitting "HTML" in lower case. ---------------------------------------------------------------------- Comment By: Björn Höhrmann (hoehrmann) Date: 2005-10-18 11:58 Message: Logged In: YES user_id=188003 If the concern is that Tidy does not add the system identifier by default then that's not a bug. ---------------------------------------------------------------------- Comment By: Arnaud Desitter (arnaud02) Date: 2005-10-17 12:56 Message: Logged In: YES user_id=566665 It looks like a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390963&aid=1324100&group_id=27659 ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl

Next Message by Date: click to view message preview

[ tidy-Bugs-1331849 ] Closing Tag ignored when Start is implied/inferred

Bugs item #1331849, was opened at 2005-10-19 09:06 Message generated for change (Comment added) made by cmwoods You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390963&aid=1331849&group_id=27659 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: HTML/XML/XHTML Parser Group: Current - all platforms Status: Open Resolution: None Priority: 5 Submitted By: Christopher M. Woods (cmwoods) Assigned to: Nobody/Anonymous (nobody) Summary: Closing Tag ignored when Start is implied/inferred Initial Comment: It appears that Tidy is ignoring the closing tag when the opening/start tag is implied when using the HASH lookup functionality (ELEMENT_HASH_LOOKUP). A trace into the code shows that: - when creating a new tag from a token in the input stream, Tidy calls lookup() [in tags.c] which will check the Hash Table and return the item. - when creating an implied/inferred tag, Tidy calls LookupTagDef() [in tags.c] which does NOT check the Hash Table (nor the custom tags table) - only the original def table. When Tidy encounters the closing tag for the element (e.g. for table close in ParseTable() [in parser.c]), it does a check to see if the tag pointers are the same (not the contents of the pointers). This comparison fails because one of the pointers is from the original def table and the other is from the hash table. I see two options to address this: 1) Change all the pointer comparisons to key/unique fields in the tag def structure. 2) Add the hash lookup functionality to LookupTagDef(): #ifdef ELEMENT_HASH_LOOKUP /* this breaks if declared elements get changed between two */ /* parser runs since Tidy would use the cached version rather */ /* than the new one */ for (np = tags->hashtab[hash(s)]; np != NULL; np = np->next) if (tmbstrcmp(s, np->name) == 0) return np; for (np = tag_defs + 1; np < tag_defs + N_TIDY_TAGS; ++np) if (tmbstrcmp(s, np->name) == 0) return install(tags, np); #else for (np = tag_defs + 1; np < tag_defs + N_TIDY_TAGS; ++np ) if (np->id == tid) return np; #endif /* ELEMENT_HASH_LOOKUP */ (Note: I did not include the declared tags list in this functional change but it probably should be included for consistency.) ---------------------------------------------------------------------- >Comment By: Christopher M. Woods (cmwoods) Date: 2005-10-19 15:01 Message: Logged In: YES user_id=576763 This issue is somewhat bigger than I originally thought and beyond the scope of what I can suggest for changes to the codebase. The core issue here lies in the usage of direct pointer comparisons when the Hash Table functionality is enabled. One area where this problem manifests is where inferred nodes are compared against non-inferred nodes (as I originally outlined). The inferred node is created with a Dict pointer reference into the tag_def static table. The non-inferred node is created with a Dict pointer reference into the hashtable dynamic table. All direct pointer comparisons will fail in this situation - which is not correct nor do I think intended. Either the direct pointer comparisons must change or the hash table must be used when creating the inferred node. I can not say that this issue is limited only to the situation in which I initially discovered above. Any code that calls LookupTagDef() or directly references the tag_def static table is suspect and needs to be reviewed. If the Dict pointer reference returned from LookupTagDef() is directly used for comparison then this code is affected as well. If the Dict pointer reference is stored then this code may or may not be affected depending on whether the stored pointer is directly compared later. Considering that no one else has reported an issue with the hash table functionality, then probably either: a) the scope is limited to only the situation that I found (aka inferred table start or potentially any inferred table) b) hash table functionality is generally not being enabled when people build the libs/application Regardless the code should be double checked. If you'd like me to delete this [messy] bug and re-file a new [clean] issue report, just let me know. ---------------------------------------------------------------------- Comment By: Christopher M. Woods (cmwoods) Date: 2005-10-19 13:59 Message: Logged In: YES user_id=576763 I must appologize here - I just C/C/P and grabbed the wrong snippet of code when I pasted my suggest code change. What I pasted does not compile but it is conceptually what needs to change. If the Hash functionality is being used then it must be used in this function as well so that the pointer comparisons used throughout the code function as originally intended. I will try to update with a corrected code change suggestion once I look into the code some more and determine how to get a clean reference to the hash table. ---------------------------------------------------------------------- Comment By: Christopher M. Woods (cmwoods) Date: 2005-10-19 13:25 Message: Logged In: YES user_id=576763 I should add to my last comment that this issue is not experienced with the new hash lookup functionality disabled - as both functions then return pointers from the tag def table. It manifests specifically because pointer comparisons are occurring and the hash table functionality creates a copy of the tag def - the pointers are different but the content is the same. This could be addressed by changing the hash logic to add an extra layer of indirection (a pointer instead of a copy) or by something similar to the change I specified in the original issue report. ---------------------------------------------------------------------- Comment By: Christopher M. Woods (cmwoods) Date: 2005-10-19 13:19 Message: Logged In: YES user_id=576763 "When Tidy encounters the closing tag for the element (e.g. for table close in ParseTable() [in parser.c]), it does a check to see if the tag pointers are the same (not the contents of the pointers). This comparison fails because one of the pointers is from the original def table and the other is from the hash table." This means that if an inferred table is started, it does not exit when </table> is encountered. Using the sample file Tidy generates: line 6 column 1 - Warning: <tr> isn't allowed in <body> elements line 9 column 1 - Warning: inserting implicit <table> line 25 column 1 - Warning: discarding unexpected </table> line 9 column 1 - Warning: plain text isn't allowed in <table> elements line 29 column 1 - Warning: missing <tr> line 29 column 1 - Warning: discarding unexpected <table> line 29 column 1 - Warning: <tr> isn't allowed in <tr> elements line 37 column 1 - Warning: discarding unexpected </tr> line 29 column 1 - Warning: <tr> isn't allowed in <tr> elements line 45 column 1 - Warning: discarding unexpected </tr> line 46 column 1 - Warning: discarding unexpected </table> line 9 column 1 - Warning: plain text isn't allowed in <table> elements line 9 column 1 - Warning: missing </table> before </body> line 9 column 1 - Warning: <table> lacks "summary" attribute The output is incorrectly ordered and the two tables are merged into one (see input vs. output in browser). ---------------------------------------------------------------------- Comment By: Björn Höhrmann (hoehrmann) Date: 2005-10-19 09:18 Message: Logged In: YES user_id=188003 Which kind of problem does this cause? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390963&aid=1331849&group_id=27659 ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl

Previous Message by Thread: click to view message preview

[ tidy-Bugs-1331849 ] Closing Tag ignored when Start is implied/inferred

Bugs item #1331849, was opened at 2005-10-19 09:06 Message generated for change (Comment added) made by cmwoods You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390963&aid=1331849&group_id=27659 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: HTML/XML/XHTML Parser Group: Current - all platforms Status: Open Resolution: None Priority: 5 Submitted By: Christopher M. Woods (cmwoods) Assigned to: Nobody/Anonymous (nobody) Summary: Closing Tag ignored when Start is implied/inferred Initial Comment: It appears that Tidy is ignoring the closing tag when the opening/start tag is implied when using the HASH lookup functionality (ELEMENT_HASH_LOOKUP). A trace into the code shows that: - when creating a new tag from a token in the input stream, Tidy calls lookup() [in tags.c] which will check the Hash Table and return the item. - when creating an implied/inferred tag, Tidy calls LookupTagDef() [in tags.c] which does NOT check the Hash Table (nor the custom tags table) - only the original def table. When Tidy encounters the closing tag for the element (e.g. for table close in ParseTable() [in parser.c]), it does a check to see if the tag pointers are the same (not the contents of the pointers). This comparison fails because one of the pointers is from the original def table and the other is from the hash table. I see two options to address this: 1) Change all the pointer comparisons to key/unique fields in the tag def structure. 2) Add the hash lookup functionality to LookupTagDef(): #ifdef ELEMENT_HASH_LOOKUP /* this breaks if declared elements get changed between two */ /* parser runs since Tidy would use the cached version rather */ /* than the new one */ for (np = tags->hashtab[hash(s)]; np != NULL; np = np->next) if (tmbstrcmp(s, np->name) == 0) return np; for (np = tag_defs + 1; np < tag_defs + N_TIDY_TAGS; ++np) if (tmbstrcmp(s, np->name) == 0) return install(tags, np); #else for (np = tag_defs + 1; np < tag_defs + N_TIDY_TAGS; ++np ) if (np->id == tid) return np; #endif /* ELEMENT_HASH_LOOKUP */ (Note: I did not include the declared tags list in this functional change but it probably should be included for consistency.) ---------------------------------------------------------------------- >Comment By: Christopher M. Woods (cmwoods) Date: 2005-10-19 13:25 Message: Logged In: YES user_id=576763 I should add to my last comment that this issue is not experienced with the new hash lookup functionality disabled - as both functions then return pointers from the tag def table. It manifests specifically because pointer comparisons are occurring and the hash table functionality creates a copy of the tag def - the pointers are different but the content is the same. This could be addressed by changing the hash logic to add an extra layer of indirection (a pointer instead of a copy) or by something similar to the change I specified in the original issue report. ---------------------------------------------------------------------- Comment By: Christopher M. Woods (cmwoods) Date: 2005-10-19 13:19 Message: Logged In: YES user_id=576763 "When Tidy encounters the closing tag for the element (e.g. for table close in ParseTable() [in parser.c]), it does a check to see if the tag pointers are the same (not the contents of the pointers). This comparison fails because one of the pointers is from the original def table and the other is from the hash table." This means that if an inferred table is started, it does not exit when </table> is encountered. Using the sample file Tidy generates: line 6 column 1 - Warning: <tr> isn't allowed in <body> elements line 9 column 1 - Warning: inserting implicit <table> line 25 column 1 - Warning: discarding unexpected </table> line 9 column 1 - Warning: plain text isn't allowed in <table> elements line 29 column 1 - Warning: missing <tr> line 29 column 1 - Warning: discarding unexpected <table> line 29 column 1 - Warning: <tr> isn't allowed in <tr> elements line 37 column 1 - Warning: discarding unexpected </tr> line 29 column 1 - Warning: <tr> isn't allowed in <tr> elements line 45 column 1 - Warning: discarding unexpected </tr> line 46 column 1 - Warning: discarding unexpected </table> line 9 column 1 - Warning: plain text isn't allowed in <table> elements line 9 column 1 - Warning: missing </table> before </body> line 9 column 1 - Warning: <table> lacks "summary" attribute The output is incorrectly ordered and the two tables are merged into one (see input vs. output in browser). ---------------------------------------------------------------------- Comment By: Björn Höhrmann (hoehrmann) Date: 2005-10-19 09:18 Message: Logged In: YES user_id=188003 Which kind of problem does this cause? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390963&aid=1331849&group_id=27659 ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl

Next Message by Thread: click to view message preview

[ tidy-Bugs-1331849 ] Closing Tag ignored when Start is implied/inferred

Bugs item #1331849, was opened at 2005-10-19 09:06 Message generated for change (Comment added) made by cmwoods You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390963&aid=1331849&group_id=27659 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: HTML/XML/XHTML Parser Group: Current - all platforms Status: Open Resolution: None Priority: 5 Submitted By: Christopher M. Woods (cmwoods) Assigned to: Nobody/Anonymous (nobody) Summary: Closing Tag ignored when Start is implied/inferred Initial Comment: It appears that Tidy is ignoring the closing tag when the opening/start tag is implied when using the HASH lookup functionality (ELEMENT_HASH_LOOKUP). A trace into the code shows that: - when creating a new tag from a token in the input stream, Tidy calls lookup() [in tags.c] which will check the Hash Table and return the item. - when creating an implied/inferred tag, Tidy calls LookupTagDef() [in tags.c] which does NOT check the Hash Table (nor the custom tags table) - only the original def table. When Tidy encounters the closing tag for the element (e.g. for table close in ParseTable() [in parser.c]), it does a check to see if the tag pointers are the same (not the contents of the pointers). This comparison fails because one of the pointers is from the original def table and the other is from the hash table. I see two options to address this: 1) Change all the pointer comparisons to key/unique fields in the tag def structure. 2) Add the hash lookup functionality to LookupTagDef(): #ifdef ELEMENT_HASH_LOOKUP /* this breaks if declared elements get changed between two */ /* parser runs since Tidy would use the cached version rather */ /* than the new one */ for (np = tags->hashtab[hash(s)]; np != NULL; np = np->next) if (tmbstrcmp(s, np->name) == 0) return np; for (np = tag_defs + 1; np < tag_defs + N_TIDY_TAGS; ++np) if (tmbstrcmp(s, np->name) == 0) return install(tags, np); #else for (np = tag_defs + 1; np < tag_defs + N_TIDY_TAGS; ++np ) if (np->id == tid) return np; #endif /* ELEMENT_HASH_LOOKUP */ (Note: I did not include the declared tags list in this functional change but it probably should be included for consistency.) ---------------------------------------------------------------------- >Comment By: Christopher M. Woods (cmwoods) Date: 2005-10-19 15:01 Message: Logged In: YES user_id=576763 This issue is somewhat bigger than I originally thought and beyond the scope of what I can suggest for changes to the codebase. The core issue here lies in the usage of direct pointer comparisons when the Hash Table functionality is enabled. One area where this problem manifests is where inferred nodes are compared against non-inferred nodes (as I originally outlined). The inferred node is created with a Dict pointer reference into the tag_def static table. The non-inferred node is created with a Dict pointer reference into the hashtable dynamic table. All direct pointer comparisons will fail in this situation - which is not correct nor do I think intended. Either the direct pointer comparisons must change or the hash table must be used when creating the inferred node. I can not say that this issue is limited only to the situation in which I initially discovered above. Any code that calls LookupTagDef() or directly references the tag_def static table is suspect and needs to be reviewed. If the Dict pointer reference returned from LookupTagDef() is directly used for comparison then this code is affected as well. If the Dict pointer reference is stored then this code may or may not be affected depending on whether the stored pointer is directly compared later. Considering that no one else has reported an issue with the hash table functionality, then probably either: a) the scope is limited to only the situation that I found (aka inferred table start or potentially any inferred table) b) hash table functionality is generally not being enabled when people build the libs/application Regardless the code should be double checked. If you'd like me to delete this [messy] bug and re-file a new [clean] issue report, just let me know. ---------------------------------------------------------------------- Comment By: Christopher M. Woods (cmwoods) Date: 2005-10-19 13:59 Message: Logged In: YES user_id=576763 I must appologize here - I just C/C/P and grabbed the wrong snippet of code when I pasted my suggest code change. What I pasted does not compile but it is conceptually what needs to change. If the Hash functionality is being used then it must be used in this function as well so that the pointer comparisons used throughout the code function as originally intended. I will try to update with a corrected code change suggestion once I look into the code some more and determine how to get a clean reference to the hash table. ---------------------------------------------------------------------- Comment By: Christopher M. Woods (cmwoods) Date: 2005-10-19 13:25 Message: Logged In: YES user_id=576763 I should add to my last comment that this issue is not experienced with the new hash lookup functionality disabled - as both functions then return pointers from the tag def table. It manifests specifically because pointer comparisons are occurring and the hash table functionality creates a copy of the tag def - the pointers are different but the content is the same. This could be addressed by changing the hash logic to add an extra layer of indirection (a pointer instead of a copy) or by something similar to the change I specified in the original issue report. ---------------------------------------------------------------------- Comment By: Christopher M. Woods (cmwoods) Date: 2005-10-19 13:19 Message: Logged In: YES user_id=576763 "When Tidy encounters the closing tag for the element (e.g. for table close in ParseTable() [in parser.c]), it does a check to see if the tag pointers are the same (not the contents of the pointers). This comparison fails because one of the pointers is from the original def table and the other is from the hash table." This means that if an inferred table is started, it does not exit when </table> is encountered. Using the sample file Tidy generates: line 6 column 1 - Warning: <tr> isn't allowed in <body> elements line 9 column 1 - Warning: inserting implicit <table> line 25 column 1 - Warning: discarding unexpected </table> line 9 column 1 - Warning: plain text isn't allowed in <table> elements line 29 column 1 - Warning: missing <tr> line 29 column 1 - Warning: discarding unexpected <table> line 29 column 1 - Warning: <tr> isn't allowed in <tr> elements line 37 column 1 - Warning: discarding unexpected </tr> line 29 column 1 - Warning: <tr> isn't allowed in <tr> elements line 45 column 1 - Warning: discarding unexpected </tr> line 46 column 1 - Warning: discarding unexpected </table> line 9 column 1 - Warning: plain text isn't allowed in <table> elements line 9 column 1 - Warning: missing </table> before </body> line 9 column 1 - Warning: <table> lacks "summary" attribute The output is incorrectly ordered and the two tables are merged into one (see input vs. output in browser). ---------------------------------------------------------------------- Comment By: Björn Höhrmann (hoehrmann) Date: 2005-10-19 09:18 Message: Logged In: YES user_id=188003 Which kind of problem does this cause? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390963&aid=1331849&group_id=27659 ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by