From wagner.patriota at gmail.com Fri May 4 01:41:54 2012 From: wagner.patriota at gmail.com (Wagner Patriota) Date: Thu, 3 May 2012 20:41:54 -0300 Subject: [Expat-discuss] compile to iOS 5.1 Message-ID: I am trying a lot of scripts to compile expat for iOS. I am on 5.1 version... can anybody help me? I want armv6 armv7 and i386.... thanks :-) From jorton at redhat.com Fri May 11 18:02:12 2012 From: jorton at redhat.com (Joe Orton) Date: Fri, 11 May 2012 17:02:12 +0100 Subject: [Expat-discuss] XML_SetHashSalt(p, 0) semantics Message-ID: <20120511160212.GA32053@redhat.com> Tomas (CC'ed) noticed that the semantics of XML_SetHashSalt are surprising when 0 is passed. That value does not force a fixed hash salt, as might be expected from reading the API description, but instead implies use of a random hash salt, per startParsing(): if (hash_secret_salt == 0) hash_secret_salt = generate_hash_secret_salt(); Which is the desired semantics? It would be simple to fix either the header or the implementation. pyexpat is apparently using XML_SetHashSalt(parser, 0) hoping for a fixed hash salt. Regards, Joe From karl at waclawek.net Fri May 11 19:16:15 2012 From: karl at waclawek.net (Karl Waclawek) Date: Fri, 11 May 2012 13:16:15 -0400 Subject: [Expat-discuss] XML_SetHashSalt(p, 0) semantics In-Reply-To: <20120511160212.GA32053@redhat.com> References: <20120511160212.GA32053@redhat.com> Message-ID: <002b01cd2f99$ca3512b0$5e9f3810$@waclawek.net> Yes, this should have been documented. Please file a bug report. 0 is used as a sentinel value that means that no secret salt value has been set and therefore one needs to be generated. In any case, one can always use another value if a fixed hash salt is desired, but I wonder why one would want to turn this off. Karl -----Original Message----- From: expat-discuss-bounces+karl=waclawek.net at libexpat.org [mailto:expat-discuss-bounces+karl=waclawek.net at libexpat.org] On Behalf Of Joe Orton Sent: May-11-12 12:02 PM To: expat-discuss at libexpat.org Cc: Kurt Seifried; Tomas Hoger; David Malcolm Subject: [Expat-discuss] XML_SetHashSalt(p, 0) semantics Tomas (CC'ed) noticed that the semantics of XML_SetHashSalt are surprising when 0 is passed. That value does not force a fixed hash salt, as might be expected from reading the API description, but instead implies use of a random hash salt, per startParsing(): if (You must write an attribute 'type'='object' after writing the attribute with local name '__type' == 0) hash_secret_salt = generate_hash_secret_salt(); Which is the desired semantics? It would be simple to fix either the header or the implementation. pyexpat is apparently using XML_SetHashSalt(parser, 0) hoping for a fixed hash salt. Regards, Joe _______________________________________________ Expat-discuss mailing list Expat-discuss at libexpat.org http://mail.libexpat.org/mailman/listinfo/expat-discuss From jorton at redhat.com Mon May 14 18:09:54 2012 From: jorton at redhat.com (Joe Orton) Date: Mon, 14 May 2012 17:09:54 +0100 Subject: [Expat-discuss] XML_SetHashSalt(p, 0) semantics In-Reply-To: <002b01cd2f99$ca3512b0$5e9f3810$@waclawek.net> References: <20120511160212.GA32053@redhat.com> <002b01cd2f99$ca3512b0$5e9f3810$@waclawek.net> Message-ID: <20120514160954.GA22469@redhat.com> On Fri, May 11, 2012 at 01:16:15PM -0400, Karl Waclawek wrote: > Yes, this should have been documented. Please file a bug report. https://sourceforge.net/tracker/?func=detail&aid=3526620&group_id=10127&atid=110127 > 0 is used as a sentinel value that means that no secret salt value has been > set and therefore one needs to be generated. > > In any case, one can always use another value if a fixed hash salt is > desired, but I wonder why one would want to turn this off. My guess: it's useful because the hash ordering randomisation fixes have a tendency to break test cases which make bad API assumptions; allowing a zero hash (and hence the old hash ordering) is at least a temporary reprieve until those test suites are fixed. Regards, Joe From karl at waclawek.net Mon May 14 18:31:16 2012 From: karl at waclawek.net (Karl Waclawek) Date: Mon, 14 May 2012 12:31:16 -0400 Subject: [Expat-discuss] XML_SetHashSalt(p, 0) semantics In-Reply-To: <20120514160954.GA22469@redhat.com> References: <20120511160212.GA32053@redhat.com> <002b01cd2f99$ca3512b0$5e9f3810$@waclawek.net> <20120514160954.GA22469@redhat.com> Message-ID: <003401cd31ef$00de3600$029aa200$@waclawek.net> How big of an issue is this? I'd rather fix the docs (which can be viewed online without a new release) than make another release for which I won't have time for a while. One could also say that it is a good thing that test cases are forced to be fixed.... Once we will do another release, would there still be a need for changing this? Maybe use another sentinel value, like 0xFFFFFFFF? Karl -----Original Message----- From: Joe Orton [mailto:jorton at redhat.com] Sent: May-14-12 12:10 PM To: Karl Waclawek Cc: expat-discuss at libexpat.org; 'Kurt Seifried'; 'Tomas Hoger'; 'David Malcolm' Subject: Re: [Expat-discuss] XML_SetHashSalt(p, 0) semantics On Fri, May 11, 2012 at 01:16:15PM -0400, Karl Waclawek wrote: > Yes, this should have been documented. Please file a bug report. https://sourceforge.net/tracker/?func=detail&aid=3526620&group_id=10127&atid=110127 > 0 is used as a sentinel value that means that no secret salt value has > been set and therefore one needs to be generated. > > In any case, one can always use another value if a fixed hash salt is > desired, but I wonder why one would want to turn this off. My guess: it's useful because the hash ordering randomisation fixes have a tendency to break test cases which make bad API assumptions; allowing a zero hash (and hence the old hash ordering) is at least a temporary reprieve until those test suites are fixed. Regards, Joe From fdrake at acm.org Mon May 14 22:01:21 2012 From: fdrake at acm.org (Fred Drake) Date: Mon, 14 May 2012 16:01:21 -0400 Subject: [Expat-discuss] XML_SetHashSalt(p, 0) semantics In-Reply-To: <003401cd31ef$00de3600$029aa200$@waclawek.net> References: <20120511160212.GA32053@redhat.com> <002b01cd2f99$ca3512b0$5e9f3810$@waclawek.net> <20120514160954.GA22469@redhat.com> <003401cd31ef$00de3600$029aa200$@waclawek.net> Message-ID: On Mon, May 14, 2012 at 12:31 PM, Karl Waclawek wrote: > One could also say that it is a good thing that test cases are forced to be fixed.... Definitely. +1 to fixing the documentation. Relying on the order of entries in a hash is a really bad thing, and they shouldn't be difficult to fix. Whatever sentinel value is used, it should be provided as a #define. I don't expect it to really matter whether it's 0 or 0xFFFFFFFF, but changing it would be an API breakage at this point. -Fred -- Fred L. Drake, Jr.? ? "A person who won't read has no advantage over one who can't read." ?? --Samuel Langhorne Clemens From shahjayesh15 at yahoo.co.in Fri May 18 17:58:28 2012 From: shahjayesh15 at yahoo.co.in (Jayesh Shah) Date: Fri, 18 May 2012 23:58:28 +0800 (SGT) Subject: [Expat-discuss] Encoding: ISO-8859-2 Message-ID: <1337356708.56005.YahooMailNeo@web192603.mail.sg3.yahoo.com> Hi Expat, ? I need to support 'ISO-8859-2' encoding to read XML file via C code. ? ? Below is the sample code that i wrote which works fine for UTF-8: XML_Parser gbl_xml_parser_ptr = NULL; gbl_xml_parser_ptr = XML_ParserCreate(NULL); XML_UseParserAsHandlerArg(gbl_xml_parser_ptr); XML_SetElementHandler(gbl_xml_parser_ptr, start_hndl, end_hndl); XML_SetCharacterDataHandler(gbl_xml_parser_ptr, char_hndl); ? To support 'ISO-8859-2', am suppose to use XML_SetUnknownEncodingHandler and write a handler. ? However, am not able to write the handler for the same. ? Please suggest ? Thanks in advance Regards,, Jayesh Shah From karl at waclawek.net Fri May 25 20:54:35 2012 From: karl at waclawek.net (Karl Waclawek) Date: Fri, 25 May 2012 14:54:35 -0400 Subject: [Expat-discuss] XML_SetHashSalt(p, 0) semantics In-Reply-To: <1337967850.2301.45.camel@surprise> References: <20120511160212.GA32053@redhat.com> <002b01cd2f99$ca3512b0$5e9f3810$@waclawek.net> <20120514160954.GA22469@redhat.com> <003401cd31ef$00de3600$029aa200$@waclawek.net> <1337967850.2301.45.camel@surprise> Message-ID: <003001cd3aa7$d5240730$7f6c1590$@waclawek.net> The comment in the patch indicates that the new defined value (XML_DISABLE_HASH_RANDOMIZATION ) disables hash randomization. I guess your point is to single out a specific value for doing this, however, this still requires the programmer to pass that same value every time the parser is used. The same effect can be achieved with any other value, as long as you never change it. The only difference would be that the hash salt would be different from old Expat versions. I would think that this could actually cloud the issue as the programmer might expect that this is the only value that disables hash randomization. In any case, no-one should rely on the hash table implementation within Expat - except hackers ;-) Furthermore, there never was a promise that the hash function used in Expat would stay the same, and changing it would not have been considered a breaking change. I am not too concerned about leaving it as it is. Karl -----Original Message----- From: David Malcolm [mailto:dmalcolm at redhat.com] Sent: May-25-12 1:44 PM To: Fred Drake Cc: karl at waclawek.net; Joe Orton; Kurt Seifried; Tomas Hoger; expat-discuss at libexpat.org Subject: Re: [Expat-discuss] XML_SetHashSalt(p, 0) semantics On Mon, 2012-05-14 at 16:01 -0400, Fred Drake wrote: > On Mon, May 14, 2012 at 12:31 PM, Karl Waclawek wrote: > > One could also say that it is a good thing that test cases are forced to be fixed.... > > Definitely. > > +1 to fixing the documentation. Relying on the order of entries in a > hash is a really bad thing, and they shouldn't be difficult to fix. > > Whatever sentinel value is used, it should be provided as a #define. > I don't expect it to really matter whether it's 0 or 0xFFFFFFFF, but > changing it would be an API breakage at this point. How about something like the attached patch (compiles, but not tested)