From noreply at sourceforge.net  Tue Apr  1 09:50:03 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Apr  1 12:35:22 2003
Subject: [Expat-bugs] [ expat-Patches-699487 ] Hash table improvement
Message-ID: <E190Ptb-0006GD-00@sc8-sf-web1.sourceforge.net>

Patches item #699487, was opened at 2003-03-07 11:31
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Karl Waclawek (kwaclaw)
Assigned to: Karl Waclawek (kwaclaw)
Summary: Hash table improvement

Initial Comment:
This patch addresses two areas:

1) The current hash function ignores the high byte
    of UTF-16 characters. This is not good.
2) There is a cheap way to switch from the current
    method of linear probing (to resolve collisions)
    to the slightly better double hashing.

Ad 1) hashing of wide characters:
Currently, the algorithm is like this:
  h = h * 33 + (unsigned char)c;
where h is the hash value and c is a character
in the string argument (char or wchar_t).

It seems this hashing algorithm belongs to a family
of algorithms of the type:
  h = h * <some number> + character
where <some number> is taken froma list of tried
and proven values like 31, 33, 37, 41, 65599 which
should be (but are not always) prime numbers.

I added a wchar_t version (#ifdef XML_UNICODE)
of this type: h = h * 65599 + (unsigned short)c;

Ad 2) double hashing:
Currently the hash table index is calculated from 
the hash value by masking out the lower bits
according to table size. This works because the
table size is a power of 2. But this also means that
some bits of the hash value are unused. From 
these we  can therefore generate the second hash 
value with little extra effort.

The patch also updates the inlined hash table 
implementation used for detecting duplicate 
prefixed attributes (in function storeAtts()).

See the attached file hashpatch1.diff
(to be applied against xmlparse.c rev. 1.109).

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-04-01 12:50

Message:
Logged In: YES 
user_id=290026

The last change is not necessary, since the cast
to unsigned char takes care of overflow. It actually
introduces a bug, since for small sizes the step size
can now be larger than the table size.

We can change back and write it like this:

#define SECOND_HASH(hash, mask, power) \
  ((((hash) & ~(mask)) >> ((power) - 1)) & ((mask) >> 2))
#define PROBE_STEP(hash, mask, power) \
  ((unsigned char)((SECOND_HASH(hash, mask, power)) | 
1))


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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-03-28 20:40

Message:
Logged In: YES 
user_id=290026

Further change for PROBE_STEP macro:
To prevent overflow (the result should fit into one Byte)
we replace "& (mask >> 2)" with "& (unsigned long)0xFF":

#define BYTE_MASK ((unsigned long)0xFF)
#define PROBE_STEP(hash, mask, power) \
  ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) \
                   & BYTE_MASK) \
   | (unsigned char)(1))

which limits the maxium step size to 0xFF.
Large steps are not a good idea anyway, since that
might lead to cache misses.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-03-24 13:29

Message:
Logged In: YES 
user_id=290026

Improvement to first patch version (hashpatch1.diff):

For calculating second hash, don't overwrite the
rightmost bit of the hash value's unused portion.
This means: change ">> (power)" to ">> ((power) - 1)":

#define PROBE_STEP(hash, mask, power) \
 ((unsigned char)((((hash) & ~(mask)) >> ((power) - 1)) & 
((mask) >> 2)) \
+   | (unsigned char)(1))


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=310127&aid=699487&group_id=10127

From noreply at sourceforge.net  Wed Apr  2 07:38:35 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr  2 10:24:22 2003
Subject: [Expat-bugs] [ expat-Bugs-713976 ] expact.h references XML_status
	before declaration
Message-ID: <E190kJv-0007zK-00@sc8-sf-web4.sourceforge.net>

Bugs item #713976, was opened at 2003-04-02 07:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=713976&group_id=10127

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: expact.h references XML_status before declaration

Initial Comment:
expat-1.95.6/lib/expact.h references XML_Status before
declaring it.  Discovered while trying to build
Sablot-0.97 from <http://www.gingerall.com/> on a Linux
Mandrake 9.0 system.

Solution was simplest move declaration and associated
comment towards the top of expat.h.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=713976&group_id=10127

From noreply at sourceforge.net  Wed Apr  2 07:55:45 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr  2 10:42:46 2003
Subject: [Expat-bugs] [ expat-Bugs-713976 ] expact.h references XML_status
	before declaration
Message-ID: <E190kaX-0000UF-00@sc8-sf-web4.sourceforge.net>

Bugs item #713976, was opened at 2003-04-02 10:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=713976&group_id=10127

Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: expact.h references XML_status before declaration

Initial Comment:
expat-1.95.6/lib/expact.h references XML_Status before
declaring it.  Discovered while trying to build
Sablot-0.97 from <http://www.gingerall.com/> on a Linux
Mandrake 9.0 system.

Solution was simplest move declaration and associated
comment towards the top of expat.h.



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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-04-02 10:55

Message:
Logged In: YES 
user_id=290026

This is a duplicate of issue #676844 and
already fixed in CVS.

Thanks for the patch anyway.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=713976&group_id=10127

From noreply at sourceforge.net  Mon Apr  7 11:38:48 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Apr  7 13:23:11 2003
Subject: [Expat-bugs] [ expat-Bugs-488899 ] Bad pointer from characterData
	handler
Message-ID: <E192aa0-0008KC-00@sc8-sf-web1.sourceforge.net>

Bugs item #488899, was opened at 2001-12-04 06:28
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=488899&group_id=10127

Category: None
Group: Platform Specific
Status: Closed
Resolution: Remind
Priority: 5
Submitted By: Paul Plummer (plummpj)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Bad pointer from characterData handler

Initial Comment:
Expat frequently returns bad data pointers to my 
handler for XML_SetCharacterDataHandler. I have expat 
V 1.95.2 installed on a SUN w Solaris 2.5.1.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-04-07 10:38

Message:
Logged In: NO 

Well, I noticed also that depending on the size of the
buffer the parser is using, the CharacterDataHandler routine
is given just a portion of the data between the start and
end tags because it is split across two buffers of xml from
the stream (a file in my case). This causes the
CharacterDataHandler to then be called again with the
remainder of the text data. Shouldn't expat put the two or
more pieces together as one string and then call the handler?

Respectfully,
Bill Lynn
blynn@jtls.nps.navy.mil

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-08-27 16:46

Message:
Logged In: YES 
user_id=3066

I just tried this again using the CVS version of Expat and
the test for a "bad pointer" disabled, and saw no ill
effects.  Please test with the CVS version of Expat if
possible.  Be sure to follow the instructions in the README
to build the XML_UNICODE version of the library.

I'll ignore this until you're able to confirm that there's
still a problem in a more current version of Expat (with a
strong preference for the CVS version).

Following up to this report on SourceForge will add this
back to my list.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-05-17 09:30

Message:
Logged In: YES 
user_id=3066

Your test for a "bad pointer" in Element::copyData() looks
strange to me, but there's definately something weird going
on.  I'll add it to my plate.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=488899&group_id=10127

From stephanie.decraene at gltrade.com  Wed Apr  9 12:38:05 2003
From: stephanie.decraene at gltrade.com (=?iso-8859-1?Q?St=E9phanie_DE_CRAENE?=)
Date: Wed Apr  9 08:13:14 2003
Subject: [Expat-bugs] EXPAT problem
Message-ID: <001a01c2fe7b$b89748b0$12051bac@pcsdecraene>

Good morning,

 

      We use EXPAT with XML files encoded in iso-8859-1

      We have followed your recommendations: ?To use this encoding,
expat must be told either by supplying an argument of "iso-8859-1" to
XML_ParserCreate, or by starting the document with <?xml version="1.0"
encoding="iso-8859-1"?>.?

       But for example if in the XML file we have ?/211? for a special
character, using EXPAT  we have this information ?/211?with ?/302?
before : ?/302/211?
 

       Is there someone you have already encountered the same problem?

       We don?t know if it is a bug or a miss-understood.

 

Thank you very much

Best regards

Stephanie 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.libexpat.org/pipermail/expat-bugs/attachments/20030409/7d129744/attachment.htm
From karl at waclawek.net  Wed Apr  9 10:17:33 2003
From: karl at waclawek.net (Karl Waclawek)
Date: Wed Apr  9 09:17:37 2003
Subject: [Expat-bugs] EXPAT problem
References: <001a01c2fe7b$b89748b0$12051bac@pcsdecraene>
Message-ID: <006901c2fe9a$617ac650$9e539696@citkwaclaww2k>

Expat reports the XML information encoded in UTF-8 or UTF-16,
even if the source is encoded in ISO-8859-1.

Karl

----- Original Message -----
From: "St?phanie DE CRAENE" <stephanie.decraene@gltrade.com>
To: <mailman-21@libexpat.org>; <expat-bugs@libexpat.org>
Cc: <magali.loison@gltrade.com>
Sent: Wednesday, April 09, 2003 5:38 AM
Subject: [Expat-bugs] EXPAT problem


Good morning,



      We use EXPAT with XML files encoded in iso-8859-1

      We have followed your recommendations: "To use this encoding,
expat must be told either by supplying an argument of "iso-8859-1" to
XML_ParserCreate, or by starting the document with <?xml version="1.0"
encoding="iso-8859-1"?>."

       But for example if in the XML file we have "/211" for a special
character, using EXPAT  we have this information "/211"with "/302"
before : "/302/211".

       Is there someone you have already encountered the same problem?

       We don't know if it is a bug or a miss-understood.



Thank you very much

Best regards

Stephanie








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


> _______________________________________________
> Expat-bugs mailing list
> Expat-bugs@libexpat.org
> http://mail.libexpat.org/mailman/listinfo/expat-bugs
>


From noreply at sourceforge.net  Wed Apr 16 06:23:04 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 16 08:05:24 2003
Subject: [Expat-bugs] [ expat-Bugs-722457 ] XML Status (expat.h)
Message-ID: <E195lwO-0006vm-00@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: XML Status (expat.h)

Initial Comment:
The enum XML_STATUS has been used before it has 
been defined in expat.h (ver 1.95.3 i think).

Just putting the whole enum just before it's being used 
solves the problem I guess. I compiled sablot for PHP 
on it... and it seems to have compiled just fine. It 
works OK too.

rollacosta@phreaker.net

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=722457&group_id=10127

From noreply at sourceforge.net  Wed Apr 16 07:57:01 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 16 09:39:50 2003
Subject: [Expat-bugs] [ expat-Bugs-722457 ] XML Status (expat.h)
Message-ID: <E195nPJ-0003Ac-00@sc8-sf-web3.sourceforge.net>

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

Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: XML Status (expat.h)

Initial Comment:
The enum XML_STATUS has been used before it has 
been defined in expat.h (ver 1.95.3 i think).

Just putting the whole enum just before it's being used 
solves the problem I guess. I compiled sablot for PHP 
on it... and it seems to have compiled just fine. It 
works OK too.

rollacosta@phreaker.net

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-04-16 09:56

Message:
Logged In: YES 
user_id=290026

Duplicate of bug #676844.
I left the old bug open so that people can see it has
already been reported. Obviously this doesn't work.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=722457&group_id=10127

From noreply at sourceforge.net  Wed Apr 16 07:59:03 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Apr 16 09:41:52 2003
Subject: [Expat-bugs] [ expat-Bugs-676844 ] expat.h compile error: enum
	XML_Status
Message-ID: <E195nRH-0003Ko-00@sc8-sf-web3.sourceforge.net>

Bugs item #676844, was opened at 2003-01-29 10:37
Message generated for change (Comment added) made by kwaclaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127

Category: Build control
Group: None
Status: Open
Resolution: Fixed
>Priority: 9
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: expat.h compile error: enum XML_Status

Initial Comment:
c++ -DHAVE_CONFIG_H -I. -I. -I../../autocfg -g -O2 -c
context.cpp  -fPIC -DPIC -o .libs/context.lo
In file included from parser.h:45,
                 from guard.h:143,
                 from context.cpp:45:
/usr/include/expat.h:657: use of enum `XML_Status'
without previous declaration
/usr/include/expat.h:736: multiple definition of `enum
XML_Status'


when building sablotron.

Hand editing the file to place the def of enum
XML_Status before any references to it fixes the problem.

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

>Comment By: Karl Waclawek (kwaclaw)
Date: 2003-04-16 09:59

Message:
Logged In: YES 
user_id=290026

Changed priority to highest to make it more visible,
so that double reporting incidents occur less frequently.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-03-27 05:42

Message:
Logged In: NO 

Same problem and the same fix under Linux and gcc 2.95.2.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-03-07 06:20

Message:
Logged In: NO 

same problem, same fix when building 1.95.6 on vms
(just downloaded .tar.gz & processed - got the rpm, but
don't know what to do with it - not an archive type I know
how to handle on vms, or windows either)
              - chris.sharman@ccagroup.co.uk

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-02-28 21:03

Message:
Logged In: YES 
user_id=290026

Strange - I had no problems with MS VC++ 6.0.
Which service pack level have you applied?

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

Comment By: Jacob Levy (jyljyljyl)
Date: 2003-02-28 20:35

Message:
Logged In: YES 
user_id=63723

This makes Expat 1.95.6 unusable for people who create
libraries that depend on Expat but don't include their own
copy of Expat. Sure, I can edit expat.h and fix it, but my
users should not be expected to do that.

For that reason I'm staying with Expat 1.95.5 until this
problem is fixed. It'd be really nice if you could make
Expat 1.95.7 soon..

In my case GCC 2.95.2 and VC++ 6.0 are complaining.


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

Comment By: Melvyn Sopacua (nyvlem)
Date: 2003-02-14 02:56

Message:
Logged In: YES 
user_id=212431

Yes, that works.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-02-06 15:47

Message:
Logged In: YES 
user_id=290026

But current CVS works for you, right?

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

Comment By: Melvyn Sopacua (nyvlem)
Date: 2003-02-06 15:17

Message:
Logged In: YES 
user_id=212431

> So far only gcc3.2 has complained.

Nope:
/usr/local/include/expat.h:657: use of enum `XML_Status' 
without previous declaration
/usr/local/include/expat.h:736: multiple definition of `enum 
XML_Status'
gmake[2]: *** [context.lo] Error 1
gmake[2]: Leaving directory 
`/home/mdev/cvs/sablot/src/engine'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/mdev/cvs/sablot/src'
gmake: *** [all-recursive] Error 1

$ gcc --version
2.95.3

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-31 09:43

Message:
Logged In: YES 
user_id=290026

It *is* fixed in CVS. Are you sure you checked out the 
right version, which is expat.h 1.51?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-01-31 05:34

Message:
Logged In: NO 

I just got the same error, already fixed it. But don't 
understand why it isn't fixed in CVS ?

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-01-29 13:44

Message:
Logged In: YES 
user_id=3066

I've not checked the C89 standard yet, but Expat 1.95.6 is 
certainly dodgy in this case.  ;-(  The first draft of the C spec I 
found online certainly seemed to imply that any use of an 
incomplete enum is not allowed; I'm not likely to go out and 
buy a copy of the final spec to check further.  ;-)

As noted, this has been fixed in CVS.  Fixed the summary to 
better indicate what this report is about, and lowered the 
priority to get it out of the way for maintainers.

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

Comment By: Karl Waclawek (kwaclaw)
Date: 2003-01-29 10:51

Message:
Logged In: YES 
user_id=290026

So far only gcc3.2 has complained.
Not sure if this is a bug, since most compilers accept it,
but it has been fixed in CVS already anyway.

Set resolution status to fixed, but leave open.
There may be other users who would report this as a bug
and I want them to see the open report instead of 
having duplicates created.

Assigned to Fred - since he may know more about
whether this truly is a bug.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=676844&group_id=10127

From noreply at sourceforge.net  Thu Apr 17 16:09:13 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Apr 17 18:09:22 2003
Subject: [Expat-bugs] [ expat-Bugs-477039 ] Compile Error on HP-UX 10_20
Message-ID: <E196HZB-0007kM-00@sc8-sf-web2.sourceforge.net>

Bugs item #477039, was opened at 2001-10-31 17:56
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=477039&group_id=10127

Category: Build control
Group: None
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: Compile Error on HP-UX 10_20

Initial Comment:
Not sure if this is a bug or just my lack of 
understanding.

Does anyone have any idea why this refuses to compile ?


$ ./configure --prefix=/opt/psfm/batch/scripts/expat
loading cache ./config.cache
checking host system type... hppa2.0-hp-hpux10.20
checking build system type... hppa2.0-hp-hpux10.20
checking for ranlib... (cached) ranlib
checking for gcc... (cached) cc
checking whether the C compiler (cc  ) works... yes
checking whether the C compiler (cc  ) is a cross-
compiler... no
checking whether we are using GNU C... (cached) no
checking whether cc accepts -g... (cached) yes
checking for non-GNU ld... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... 
(cached) no
checking for BSD-compatible nm... 
(cached) /usr/bin/nm -p
checking whether ln -s works... (cached) yes
checking whether we are using GNU C... no
checking for object suffix... o
checking for executable suffix... no
checking for cc option to produce PIC... +Z
checking if cc PIC flag +Z works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.lo... yes
checking if cc static flag -Wl,-a -Wl,archive 
works... -Wl,-a -Wl,archive
checking if the linker (/usr/bin/ld) is GNU ld... no
checking whether the linker (/usr/bin/ld) supports 
shared libraries... yes
checking command to parse /usr/bin/nm -p output... ok
checking how to hardcode library paths into 
programs... relink
checking for /usr/bin/ld option to reload object 
files... -r
checking dynamic linker characteristics... hpux10.20 
dld.sl
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
loading cache ./config.cache
checking for gcc... (cached) cc
checking whether the C compiler (cc -g ) works... yes
checking whether the C compiler (cc -g ) is a cross-
compiler... no
checking whether we are using GNU C... (cached) no
checking whether cc accepts -g... (cached) yes
checking for a BSD compatible install... 
(cached) /opt/imake/bin/install -c
checking how to run the C preprocessor... (cached) cc -
E
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for unistd.h... (cached) yes
checking whether byte ordering is bigendian... 
(cached) yes
checking for working const... (cached) no
checking for off_t... (cached) yes
checking for size_t... (cached) yes
checking for 8-bit clean memcmp... (cached) yes
checking for unistd.h... (cached) yes
checking for getpagesize... (cached) yes
checking for working mmap... (cached) no
checking for memmove... (cached) yes
checking for bcopy... (cached) yes
creating ./config.status
creating Makefile
creating lib/Makefile
creating lib/expat.h
creating xmlwf/Makefile
creating examples/Makefile
creating config.h
config.h is unchanged
$ make
$ make install
        for dir in lib xmlwf; do \
                (cd $dir && make install); \
        done
        /bin/sh ../libtool --mode=compile cc -
DHAVE_CONFIG_H -DPACKAGE='"expat"'
 -DVERSION='"expat_1.95.2"' -I. -I. -I..  -g -c 
xmlparse.c
rm -f .libs/xmlparse.lo
cc -DHAVE_CONFIG_H -DPACKAGE=\expat\ -
DVERSION=\expat_1.95.2\ -I. -I. -I.. -
g -c xmlparse.c  +Z -DPIC -o .libs/xmlparse.lo
cc: "expat.h", line 80: error 1000: Unexpected 
symbol: "XML_Char".
cc: "expat.h", line 81: error 1000: Unexpected 
symbol: "*".
cc: error 2017: Cannot recover from earlier errors, 
terminating.
*** Error exit code 1

Stop.
        cc -g -I../lib -c xmlwf.c
cpp: "xmltchar.h", line 3: warning 2013: Unknown 
preprocessing directive.
cc: "../lib/expat.h", line 80: warning 5: "const" will 
become a keyword.
cc: "../lib/expat.h", line 80: error 1000: Unexpected 
symbol: "const".
cc: "../lib/expat.h", line 81: error 1000: Unexpected 
symbol: "*".
cc: error 2017: Cannot recover from earlier errors, 
terminating.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
$


Regards,

Paul
__________________________________________________
Technical Designer
Peoplesoft Operations
IT@AMP
Level 3, 151 Clarence St, Sydney 2000
Ph: +61-2-82962621
Email: paul_rashleigh@amp.com.au


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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-04-17 15:09

Message:
Logged In: NO 

I received the same error.  Its not a missing header file, 
because XML_Char is being defined as a typedef only a few 
lines above in the header file where the error is being 
discovered.

Here is what I found.  For some weird reason, the compiler is 
expecting the function headers to be in the old style form, i.e.:

type function_name (var1, var2, var3, ...)
type1 var1;
type2 var2;
type3 var3;

When I changed the headers in expat.h, it suddenly got past 
each one that I changed, but now its getting more errors 
apparently of a different nature.

I know it sounds crazy, but there it is.  Email is 
mozart@ryanspc.com

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-19 15:00

Message:
Logged In: YES 
user_id=3066

The way the includes are set up has changed in the CVS
version of Expat.  Please try again using either the CVS
version or the upcoming 1.95.3 release.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-26 10:18

Message:
Logged In: NO 

Anything been done on this? I'm also getting the same 
problem on HP-UX 10.20 using the aCC compiler

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-06 12:27

Message:
Logged In: NO 

been able to compile it with gmake and gcc on HPUX 10.20 
800 serie.. (version 2.9x)..

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

Comment By: Weixiong He (weixionghe)
Date: 2002-01-15 11:03

Message:
Logged In: YES 
user_id=424747

It seems to me that the xmldef.h is missing from the lib 
directory. Any ideas? Thanks.

Weixiong

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-01-12 21:49

Message:
Logged In: NO 

The error appears to indicate that a needed include file is
not being included properly.  XML_Char is a #define.  Check
the -I (Uppercase i) options.  Sometimes a space is allowed
other times is not.  I have seen this problem with the -L
options some loaders also. (space required/not allowed).  
There may be specific requirements for the "C" compiler that
is actually being used.  Also, make sure you have a recent
version of libtools.

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

Comment By: Weixiong He (weixionghe)
Date: 2002-01-11 09:14

Message:
Logged In: YES 
user_id=424747

I'm doing the exact same installation as Paul, and I'm 
getting the exact same error messages as Paul's. Could 
anyone help us with it? Please!!! Thank you.

Weixiong He

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=477039&group_id=10127

From davidson_jeff at yahoo.com  Wed Apr 30 13:49:13 2003
From: davidson_jeff at yahoo.com (jeff davidson)
Date: Wed Apr 30 15:49:17 2003
Subject: [Expat-bugs] open vms/expat V1.95.6/XMLPARSEAPI(enum XML_Status)
Message-ID: <20030430194913.47003.qmail@web20804.mail.yahoo.com>

received the error below when building on open vms.

regards,
jd

CC
/DEFINE=(PACKAGE="""expat""",VERSION="""expat_1.95.3""")
/INCLUDE=([],[.lib])
  /NOLIST/OBJECT=XMLPARSE.OBJ [.LIB]XMLPARSE.C
 
XMLPARSEAPI(enum XML_Status)
^
%CC-W-UNDEFENUM, In this declaration, the enum
"XML_Status" is not defined.
at line number 656 in file
SYS$SPECIFIC:[MQS_SERVER.EXPAT.EXPAT-1.95.6.LIB]EXPAT
.H;1
%MMK-F-ERRUPD, error status %X10B91260 occurred when
updating target XMLPARSE.OB
J

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

From fdrake at acm.org  Wed Apr 30 17:08:05 2003
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed Apr 30 16:08:41 2003
Subject: [Expat-bugs] open vms/expat V1.95.6/XMLPARSEAPI(enum XML_Status)
In-Reply-To: <20030430194913.47003.qmail@web20804.mail.yahoo.com>
References: <20030430194913.47003.qmail@web20804.mail.yahoo.com>
Message-ID: <16048.11557.942127.943484@grendel.zope.com>


jeff davidson writes:
 > received the error below when building on open vms.

Can you submit this bug on SourceForge?  That will help us not lose
the report.  This is especially important for platforms, like VMS, for
which we rely on external contributors.

http://sourceforge.net/tracker/?atid=110127&group_id=10127&func=browse

Thanks!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

From karl at waclawek.net  Wed Apr 30 22:23:09 2003
From: karl at waclawek.net (Karl Waclawek)
Date: Wed Apr 30 21:17:33 2003
Subject: [Expat-bugs] open vms/expat V1.95.6/XMLPARSEAPI(enum XML_Status)
References: <20030430194913.47003.qmail@web20804.mail.yahoo.com>
	<16048.11557.942127.943484@grendel.zope.com>
Message-ID: <010001c30f80$3a370260$0207a8c0@karl>


> 
> jeff davidson writes:
>  > received the error below when building on open vms.
> 
> Can you submit this bug on SourceForge?  That will help us not lose
> the report.  This is especially important for platforms, like VMS, for
> which we rely on external contributors.
> 
> http://sourceforge.net/tracker/?atid=110127&group_id=10127&func=browse
> 
> Thanks!


But Fred,

isn't that one of the many duplicates we have for bug # 676844?

Karl

From fdrake at acm.org  Wed Apr 30 23:28:15 2003
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Wed Apr 30 22:28:51 2003
Subject: [Expat-bugs] open vms/expat V1.95.6/XMLPARSEAPI(enum XML_Status)
In-Reply-To: <010001c30f80$3a370260$0207a8c0@karl>
References: <20030430194913.47003.qmail@web20804.mail.yahoo.com>
	<16048.11557.942127.943484@grendel.zope.com>
	<010001c30f80$3a370260$0207a8c0@karl>
Message-ID: <16048.34367.35023.181647@grendel.zope.com>


Karl Waclawek writes:
 > But Fred,
 > 
 > isn't that one of the many duplicates we have for bug # 676844?

'fraid so.  My own reaction to the first few lines of this was to
ignore the rest (which contained the more obvious clues) and ask that
it be filed.

Fortunately, Jeff was on the ball and noticed that it was a
duplicate.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation