headers
SourceForge.net | 24 Apr 2013 21:18
Picon

[ expat-Bugs-3611241 ] Turning off utf16 support

Bugs item #3611241, was opened at 2013-04-17 16:24
Message generated for change (Comment added) made by csiki
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3611241&group_id=10127

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: None
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: András Csikvári (csiki)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Turning off utf16 support

Initial Comment:
It would be very nice if we could able to turn off the utf16 support for an even smaller code size in a future release.
Like XML_MIN_SIZE macro, we could define an XML_NO_UTF16 macro.
Thank you,
   András

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

>Comment By: András Csikvári (csiki)
Date: 2013-04-24 12:18

Message:
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 22 Apr 2013 15:13
Picon

[ expat-Bugs-3611241 ] Turning off utf16 support

Bugs item #3611241, was opened at 2013-04-17 16:24
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3611241&group_id=10127

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: None
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: András Csikvári (csiki)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Turning off utf16 support

Initial Comment:
It would be very nice if we could able to turn off the utf16 support for an even smaller code size in a future release.
Like XML_MIN_SIZE macro, we could define an XML_NO_UTF16 macro.
Thank you,
   András

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2013-04-22 06:13

Message:
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 20 Apr 2013 17:46
Picon

[ expat-Bugs-3611466 ] Can't install lib64expat1-dev

Bugs item #3611466, was opened at 2013-04-20 08:46
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3611466&group_id=10127

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: Build control
Group: Test Required
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Greg Stein (gstein)
Summary: Can't install lib64expat1-dev

Initial Comment:
wani <at> tester:~$ sudo apt-get install lib64expat1-dev 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 18 Apr 2013 01:24
Picon

[ expat-Bugs-3611241 ] Turning off utf16 support

Bugs item #3611241, was opened at 2013-04-17 16:24
Message generated for change (Tracker Item Submitted) made by csiki
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3611241&group_id=10127

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: www.libexpat.org
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: András Csikvári (csiki)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Turning off utf16 support

Initial Comment:
It would be very nice if we could able to turn off the utf16 support for an even smaller code size in a future release.
Like XML_MIN_SIZE macro, we could define an XML_NO_UTF16 macro.
Thank you,
   András

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3611241&group_id=10127
_______________________________________________
Expat-bugs mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philip Schneider | 15 Mar 2013 17:33
Favicon

Build errors

Greetings -

My apologies if this has already been covered, but I'm not quite sure if/how I can "grep" the archives to see if it has been…

Just downloaded the expat.tar.gz (onto Mac), and tried to start a build. From the results, it seems that the "./configure" scheme is a bit out of date? Here's what happens (the ">" signifies my bash prompt, the other text is the output to the shell)...

> ./buildconf.sh

Creating configure ...
autoreconf: Entering directory `.'
autoreconf: configure.in: not using Gettext
autoreconf: running: aclocal --force 
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
aclocal: error: couldn't open directory 'm4': No such file or directory
autoreconf: aclocal failed with exit status: 1

Now, in the MANIFEST file, I see that there should be an m4 directory, with these contents:

m4/libtool.m4
m4/ltversion.m4
m4/ltoptions.m4
m4/ltsugar.m4
m4/lt~obsolete.m4

However, these files are not part of the download, nor can I find them on the expat source server (perhaps I just missed them?)

I can try to get around this by editing configure.in, and commenting out this line:

    AC_CONFIG_MACRO_DIR([m4])

I then re-run:

> ./buildconf.sh

This succeeds, or at least there are no errors. So then I try the next step:

< ./configure
configure: error: cannot find install-sh, install.sh, or shtool in conftools "."/conftools

I see that the conftools directory indeed has none of these. Again, they are listed in the MANIFEST, but are not part of the download, nor can I find them on the server:

conftools/PrintPath
conftools/ac_c_bigendian_cross.m4
conftools/expat.m4
conftools/get-version.sh
conftools/mkinstalldirs
conftools/config.guess
conftools/config.sub
conftools/install-sh
conftools/ltmain.sh

It does seem that the cmake build scheme works, so I can probably go with that. But, I'd prefer the "./configure" approach, as it's more consistent with the many other packages I use. I'm guessing these missing files once were part of the system. Any chance this can get resurrected? 

Thanks..

-- Philip

_______________________________________________
Expat-bugs mailing list
Expat-bugs <at> libexpat.org
http://mail.libexpat.org/mailman/listinfo/expat-bugs
Permalink | Reply | 0 comments |
headers
Christoph Thompson | 24 Jan 2013 05:32
Picon

CMake build problems with expat 2.1.0 and a patch to fix them

Hi,

I ran into the following problems while trying to build expat 2.1.0 with CMake:

* I couldn't set the directories for man pages and libraries. Some Linux distros such as
Slackware put the man pages in /usr/man instead of /usr/share/man and on x86_64
libs go into /usr/lib64. It's useful when you can override the defaults from the command
line like:

cmake -DMAN_INSTALL_DIR=PATH:"/usr/man" -DLIB_INSTALL_DIR=PATH:"/usr/lib64"

So I made all this configurable instead of being hardcoded.

* The pkgconfig file was not generated correctly for /usr/lib64 since it was hardcoding /usr/lib.
Also it's nice when you can set the include dir so you can put the headers in /usr/include/expat for example. The exec_prefix is not 'bin', I don't know what it's used for, but all .pc files I have ever seen just set it to ${prefix}. So it seems safe to do that here too.

* xmlwf couldn't be built because the compiler couldn't write the xmlwf executable at the root
of the source because there was already a directory named xmlwf. The solution to that was to
make another CMakeLists.txt inside the xmlwf directory with the part about building it.

* The expat shared library wasn't built with the usual sonames. So I fixed that too.

I hope you will find my patch helpful.

Regards,

C. Thompson
Attachment (expat-2.1.0-cmakefixes.patch): application/octet-stream, 3602 bytes
_______________________________________________
Expat-bugs mailing list
Expat-bugs <at> libexpat.org
http://mail.libexpat.org/mailman/listinfo/expat-bugs
Permalink | Reply | 0 comments |
headers
SourceForge.net | 14 Dec 2012 19:18
Picon

[ expat-Bugs-3596044 ] Parser crash with *.xml.tar.gz file as input.

Bugs item #3596044, was opened at 2012-12-14 10:18
Message generated for change (Tracker Item Submitted) made by shanmukhpatel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3596044&group_id=10127

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: www.libexpat.org
Group: Third-party Bug
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Shanmukh (shanmukhpatel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Parser crash with *.xml.tar.gz file as input. 

Initial Comment:
I was using xml library to parse a file which is compressed. I was expecting an error message if the format is
invalid, but the parser crashes if I provide the *.xml.tar.gz file. I have attached the file (the same file
got it from
https://sourceforge.net/tracker/?func=detail&aid=1990430&group_id=10127&atid=110127). 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3596044&group_id=10127
Permalink | Reply | 6 comments |
headers
SourceForge.net | 13 Oct 2012 08:46
Picon

[ expat-Bugs-3576997 ] c99 errors

Bugs item #3576997, was opened at 2012-10-12 23:33
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3576997&group_id=10127

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: Build control
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: James Michael DuPont ()
Assigned to: Greg Stein (gstein)
Summary: c99 errors

Initial Comment:
gcc -I./lib -I. -std=c99 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions 
-DHAVE_EXPAT_CONFIG_H -o xmlwf/unixfilemap.o -c xmlwf/unixfilemap.c
xmlwf/unixfilemap.c: In function ‘filemap’:
xmlwf/unixfilemap.c:54: error: ‘caddr_t’ undeclared (first use in this function)
xmlwf/unixfilemap.c:54: error: (Each undeclared identifier is reported only once
xmlwf/unixfilemap.c:54: error: for each function it appears in.)
xmlwf/unixfilemap.c:54: error: expected ‘)’ before numeric constant
xmlwf/unixfilemap.c:55: error: too few arguments to function ‘mmap’
xmlwf/unixfilemap.c:62: error: expected ‘)’ before ‘p’
xmlwf/unixfilemap.c:62: error: too few arguments to function ‘munmap’
make: *** [xmlwf/unixfilemap.o] Error 1

patch will be coming.

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

>Comment By: James Michael DuPont ()
Date: 2012-10-12 23:46

Message:
patch :
Index: xmlwf/unixfilemap.c
===================================================================
RCS file: /cvsroot/expat/expat/xmlwf/unixfilemap.c,v
retrieving revision 1.9
diff -r1.9 unixfilemap.c
19a20,21
> typedef __caddr_t caddr_t;
>

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3576997&group_id=10127
_______________________________________________
Expat-bugs mailing list
Expat-bugs <at> libexpat.org
http://mail.libexpat.org/mailman/listinfo/expat-bugs
Permalink | Reply | 0 comments |
headers
SourceForge.net | 13 Oct 2012 08:33
Picon

[ expat-Bugs-3576997 ] c99 errors

Bugs item #3576997, was opened at 2012-10-12 23:33
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3576997&group_id=10127

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: Build control
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: James Michael DuPont ()
Assigned to: Greg Stein (gstein)
Summary: c99 errors

Initial Comment:
gcc -I./lib -I. -std=c99 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions 
-DHAVE_EXPAT_CONFIG_H -o xmlwf/unixfilemap.o -c xmlwf/unixfilemap.c
xmlwf/unixfilemap.c: In function ‘filemap’:
xmlwf/unixfilemap.c:54: error: ‘caddr_t’ undeclared (first use in this function)
xmlwf/unixfilemap.c:54: error: (Each undeclared identifier is reported only once
xmlwf/unixfilemap.c:54: error: for each function it appears in.)
xmlwf/unixfilemap.c:54: error: expected ‘)’ before numeric constant
xmlwf/unixfilemap.c:55: error: too few arguments to function ‘mmap’
xmlwf/unixfilemap.c:62: error: expected ‘)’ before ‘p’
xmlwf/unixfilemap.c:62: error: too few arguments to function ‘munmap’
make: *** [xmlwf/unixfilemap.o] Error 1

patch will be coming.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3576997&group_id=10127
_______________________________________________
Expat-bugs mailing list
Expat-bugs <at> libexpat.org
http://mail.libexpat.org/mailman/listinfo/expat-bugs
Permalink | Reply | 0 comments |
headers
SourceForge.net | 26 Jul 2012 06:46
Picon

[ expat-Bugs-3541525 ] Infinite loop in lib/xmlparse.c:XML_GetBuffer

Bugs item #3541525, was opened at 2012-07-09 00:12
Message generated for change (Comment added) made by polinenibharat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3541525&group_id=10127

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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: http://kasten76.myopenid.com/ ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Infinite loop in lib/xmlparse.c:XML_GetBuffer

Initial Comment:
Hi,
first thanks for maintaining expat.

I found this bug in version 2.0.1 but the code is the same in the current developement version.

When XML_GetBuffer is called and bufferSize is 0 it will be initialised to INIT_BUFFER_SIZE (1024). Which
is doubled until it is bigger than needeSize (line 1718). For my example neededSize was 
(gdb) p neededSize
$2 = 2128558980

The doubling is optimized to a shift opertaion (gcc 4.7.0). The doubling shifts the true bit in bufferSize
out of scope without breaking the loop.

(gdb) p 1024 << 20
$10 = 1073741824
(gdb) p 1024 << 21
$11 = -2147483648
(gdb) p 1024 << 22
$12 = 0

And then goes into an endless loop.

Still searching why the buffer is so huge but i wanted to mention this bug anyway.

Regards.

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

Comment By: Bharat (polinenibharat)
Date: 2012-07-25 21:46

Message:
Hi Karl,

There is a small logical overlooking of extreme cases in lines 1718 - 1722,
in lib / xmlparse.c : XML_GetBuffer

******
if (bufferSize == 0)
        bufferSize = INIT_BUFFER_SIZE;
do {
        bufferSize *= 2;
} while (bufferSize < neededSize);

******

Here the do - while is going into an infinite loop because of the Shift
operation << 1
that the compiler is performing at the line 1721 -> bufferSize *= 2;      
Here if bufferSize is 0, this loop is infinite.

Since they are all integers, if the neededSize is anything between [2^30+1,
2^31-1] the bufferSize will eventually shift to become 0 and goes infinite.

To overcome this an easy and simple solution without changing much code
could be to add the line,
bufferSize += 1; ( after line number 1721 ). 

This will ensure that the condition (bufferSize < neededSize) will be
evaluated to false for any value of neededSize, because at some stage
bufferSize will be equal to 2^31-1, the highest possible integer value
before overflow. Since the allotted buffer size can be dynamic based on our
neededSize, it should not change the structure significantly.

final code:
************
if (bufferSize == 0)
        bufferSize = INIT_BUFFER_SIZE;
do {
        bufferSize *= 2;
        bufferSize += 1;
} while (bufferSize < neededSize);

***********
I am new to open source and am sorry I did not know how to submit the patch
at the patch tracker. Hoping it helped. If its ok I'd like to look at as
many open bugs. I really got to liking expat more after looking through the
code :)

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2012-07-24 08:59

Message:
We are grateful for patches to Expat bugs. Patches should be submitted to
the Patch tracker. Thank you.

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

Comment By: Bharat (polinenibharat)
Date: 2012-07-23 22:59

Message:
Hi this looks great. I started working on it. Please assign it to me.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3541525&group_id=10127
Permalink | Reply | 0 comments |
headers
SourceForge.net | 24 Jul 2012 16:05
Picon

[ expat-Bugs-3524730 ] potential null pointer dereference

Bugs item #3524730, was opened at 2012-05-08 06:56
Message generated for change (Comment added) made by sahegde1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3524730&group_id=10127

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: None
Group: Test Required
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tomaszmi (tomaszmi)
Assigned to: Nobody/Anonymous (nobody)
Summary: potential null pointer dereference

Initial Comment:
Expat version 2.1.0

There may be a potential null pointer dereference in the xmlparse.c file, line 2914. The lookup function
may return NULL and this case is not checked before the line #2914. I'm not familiar with expat details,
however in general if such case is not possible, it would be good to make sure the program will be
terminated/aborted, for instance using assert:
assert(id);

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

Comment By: Sandeep L Hegde (sahegde1)
Date: 2012-07-24 07:05

Message:
Sorry, i am a newbie to open source. How do i add myself to the list.

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

Comment By: tomaszmi (tomaszmi)
Date: 2012-07-24 00:34

Message:
sahegde1, you are not on the list of people available to be assigned to it.

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

Comment By: Sandeep L Hegde (sahegde1)
Date: 2012-07-23 22:57

Message:
I would like to work on this bug. Please assign it to me.

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

Comment By: tomaszmi (tomaszmi)
Date: 2012-05-08 07:51

Message:
The similar issue is in the xmlparse.c, line #5478. The id->prefix may be
set to null however in the next line the pointer is dereferenced without
any check.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=3524730&group_id=10127
Permalink | Reply | 1 comment |

Gmane