df-xmldecode-patch #1

df · 2021-01-15T01:20:48Z

df commented

2021-01-15 01:20:48 +00:00

theTVDB.com started sending single quotes in XML encoded as ' rather than " as observed in this thread.

One fix was to webif/lib/xml.class; however this program replicates the decoding process in the Jim class (which is a lot slower) and needs to be fixed as well.

The patch uses sscanf() to detect and decode numerically coded XML character entities within the original framework of the unescape() function.

Modified compilation options:

-std=c99 for the hh format size prefix
-D_XOPEN_SOURCE=700 for correct declaration of strdup() in the on-box build environment.

theTVDB.com started sending single quotes in XML encoded as `'` rather than `"` as observed in [this thread](https://hummy.tv/forum/threads/special-characters-sweeper-rename-39-instead-of.9638). One fix was to `webif/lib/xml.class`; however this program replicates the decoding process in the Jim class (which is a lot slower) and needs to be fixed as well. The patch uses `sscanf()` to detect and decode numerically coded XML character entities within the original framework of the `unescape()` function. Modified compilation options: * `-std=c99` for the `hh` format size prefix * `-D_XOPEN_SOURCE=700` for correct declaration of `strdup()` in the on-box build environment.

df added 3 commits 2021-01-15 01:20:49 +00:00

Add more decoding of XML character entities 68c33866cd

Build without warnings on-box 5aeab9da9d

Ensure ; immediately follows the code in &#<hex/dec>; cf86aaebca

df changed title from ~~WIP: df-xmldecode-patch~~ to df-xmldecode-patch

2021-01-16 11:28:56 +00:00

df commented

2021-01-16 11:32:29 +00:00

Apparently does the job but the build needs to be tested in the usual environment.

af123 reviewed 2021-01-16 21:27:41 +00:00

tvdb.c

						
				@@ -61,0 +58,4 @@

						/* sscanf -> 1: the code was read; ll>0: ';' came next */

						if ((1 == sscanf( p, "&#%hhu;%n", &icode, &ll) ||

						     1 == sscanf( p, "&#%*[xX]%hhx;%n", &icode, &ll)) && 

						     ll > 0) {

af123 commented

2021-01-16 21:27:41 +00:00

sscanf() will return 2 if two input items were converted, won't it?

`sscanf()` will return 2 if two input items were converted, won't it?

af123 marked this conversation as resolved

df commented

2021-01-16 22:11:50 +00:00

sscanf() will return 2 if two input items were converted, no?

You'd think so, but free30 and I have both run the version built from that code, so apparently not, and I am more confident of that based on the following.

POSIX (admittedly a racily anachronistic 2017 version says):

"Upon successful completion, these functions shall return the number of
successfully matched and assigned input items;"

Arguably, as %n doesn't involve any matching, it doesn't count towards the result.

Also, as %*[xX] doesn't involve any assigning, it also doesn't count.

In the library source I see this (libc/stdio/_scanf.c l.1331ff):

                        if (psfs.conv_num == CONV_n) {               
#ifdef __UCLIBC_MJN3_ONLY__
#warning CONSIDER: Should %n count as a conversion as far as EOF return value?
#endif                                                               
/*                              zero_conversions = 0; */      
                                if (psfs.store) {                     
                                        _store_inttype(psfs.cur_ptr, psfs.dataargtype,   
                                                          (uintmax_t) sc.nread);
                                }
                                goto NEXT_FMT;                          
                        }

So MJN3 decided that %n didn't cause zero_conversions to be cleared, which is done for formats like %s, %d.

Also, the 0/1 flag (unsigned char store) member that is cleared/set according to whether the format contains * to suppress assignment is used to increment the return count.

> sscanf() will return 2 if two input items were converted, no? You'd think so, but free30 and I have both run the version built from that code, so apparently not, and I am more confident of that based on the following. POSIX (admittedly a racily anachronistic 2017 version says): "Upon successful completion, these functions shall return the number of successfully matched and assigned input items;" Arguably, as `%n` doesn't involve any matching, it doesn't count towards the result. Also, as `%*[xX]` doesn't involve any assigning, it also doesn't count. In the library source I see this (`libc/stdio/_scanf.c` l.1331ff): ``` if (psfs.conv_num == CONV_n) { #ifdef __UCLIBC_MJN3_ONLY__ #warning CONSIDER: Should %n count as a conversion as far as EOF return value? #endif /* zero_conversions = 0; */ if (psfs.store) { _store_inttype(psfs.cur_ptr, psfs.dataargtype, (uintmax_t) sc.nread); } goto NEXT_FMT; } ``` So MJN3 decided that %n didn't cause `zero_conversions` to be cleared, which is done for formats like %s, %d. Also, the 0/1 flag (`unsigned char store`) member that is cleared/set according to whether the format contains `*` to suppress assignment is used to increment the return count.

af123 merged commit 4d47fea182 into master

2021-01-18 22:57:11 +00:00

af123 referenced this issue from a commit

2021-01-18 22:57:12 +00:00

Merge pull request 'df-xmldecode-patch' (#1) from df/tvdb:df-xmldecode-patch into master

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hummypkg/tvdb#1

Allow edits from maintainers