I downloaded http://xml.apache.org/dist/Xerces-C_1_0_0d01.tar.gz on 2nd
December and tried to build it.  I encountered some trivial problems -- the
most least trivial problem was simply that GNU make didn't stop when a
compilation failed!

I ran runConfigure by saying:
        runConfigure -p solaris -c cc -x CC -m inmem
uname -a reports:
        SunOS serv01 5.5.1 Generic_103640-27 sun4m sparc
SUNW,SPARCstation-20
CC -V reports:
        CC: WorkShop Compilers 4.2 16 Jun 1998 C++ 4.2 patch 104631-07

The quick hacks I made to get things to build are documented below.

A further problem was that error messages did not appear.  The source of the
problem seems to be that the in-memory message loader
(src/util/MsgLoaders/InMemory/InMemMsgLoader.cpp) needlessly byte-swaps the
messages as it loads them and this causes them not to be output.  There is a
comment that says that the messages are in little-endian form (yeeugh!) but
this appears not to be true.  CppErrMsgs_EN_US.cpp starts of "0x0057" so it
looks as if the messages will use the hardware native endianness (suggesting
that no swapping is ever needed).  Certainly in my configuration (see below)
replacing the line
        #if defined(ENDIANMODE_LITTLE)
by
        #if (1)
fixed the problem.

Some further thoughts:

The in-memory loader appears not to check that the message ID is in range
even though the number of messages in a given category appears to be
available.  That's bad.

What happens if a message is not found?    The code I've looked at has a
"TBD" comment saying that a default message should be loaded.  It would be
better if the message loader supplied a default message (there are only a
handful of message loader methods but many places where they are invoked.)
The else-case should insert a message of the form
        [unable to load message {message-set}#{message-id}; parameters: {0},
{1}, {2}, {3}]
into the buffer (but still return false -- so that callers have the chance
to do their own error handling of they wish to).

What happens if not all parameters are used?  In the past I've found it a
major pain if they are discarded; it's better to tack a note of their value
onto the end of the message, e.g.
        [unused parameters: 3:foo, 4:bar]

-- julian pardoe --

======================================================================
*** SunCCDefs.hpp.bak   Fri Nov 12 23:15:08 1999
--- SunCCDefs.hpp       Thu Dec  2 13:23:39 1999
***************
*** 82,87 ****
--- 82,100 ----
  //  Define our version of the XML character
  //
---------------------------------------------------------------------------
  typedef unsigned short XMLCh;
+ #if 0  // JBDP: defined in VCPPDefs.hpp but also in XML4CDefs.hpp
+ typedef unsigned short UTF16Ch;
+ #endif
+ 
+ 
+ #if 1  // JBDP: definitions copies from VCPPDefs.hpp
+ //
---------------------------------------------------------------------------
+ //  Define unsigned 16 and 32 bits integers
+ //
---------------------------------------------------------------------------
+ typedef unsigned short  XMLUInt16;
+ typedef unsigned int    XMLUInt32;
+ #endif
+ 
  
  
  //
---------------------------------------------------------------------------
*** IconvTransService.cpp.bak   Fri Nov 12 23:15:21 1999
--- IconvTransService.cpp       Thu Dec  2 15:35:46 1999
***************
*** 73,78 ****
--- 73,83 ----
  #if defined (XML_GNUG)
  #include <wctype.h>
  #endif
+ #if defined (XML_SUNCC) // JBDP
+ #include <widec.h>
+ #define wcscasecmp    wscasecmp
+ #define wcsncasecmp   wsncasecmp
+ #endif
  #include <string.h>
  #include <stdlib.h>
  #include <stdio.h>


This message is for the named person's use only.  It may contain
confidential, proprietary or legally privileged information.  No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender.  You must not, directly or indirectly, use, disclose, distribute, 
print, or copy any part of this message if you are not the intended 
recipient. CREDIT SUISSE GROUP, CREDIT SUISSE FIRST BOSTON, and each of
their subsidiaries each reserve  the right to monitor all e-mail 
communications through its networks.  Any views expressed in this message
are those of the individual sender, except where the message states 
otherwise and the sender is authorised to state them to be the views of 
any such entity.
.


Reply via email to