(fixed in 11.5)

Another bug in MDF_TRIMWHITESPACE and MDF_COLLAPSEWHITESPACE. With one of these flags turned on in SetDocFlags, GetData will return "a" instead of "a <" (losing the encoded less than sign) in the following XML:

<t> a &lt; </t>

Fix for 11.4: in Markup.cpp:3076 insert code to set nCharWhitespace = 0 as follows:

  if ( pSource[nChar] == '&' )
  {
    if ( bAlterWhitespace )
      nCharWhitespace = 0;

    // Get corresponding unicode code point
    int nUnicode = 0;

CMarkup xml;
xml.SetDocFlags(CMarkup::MDF_COLLAPSEWHITESPACE);
... if (xml.GetChildData().length() <= 0)

<?xml version="1.0" encoding="utf-8"?>
<Properties>
  <MdlData>
    <Path>\DIR\PATH\</Path>
    <Name>0123_4567</Name>
    <Type>ABC</Type>
  </MdlData>
  <Parameters>
    <Parameter>
      <Name>XYZ_PART_NO</Name>
      <Value>
      </Value>
    </Parameter>
    <Parameter>

When reading [the Value element data], my code crashes.

(fixed in 11.1)

If you are using either read or write file mode (the Open method) this is an important fix. Please replace the ElemStack Unslot method in Markup.cpp line 1274 as follows:

void Unslot( TagPos& lp ) { int n=lp.iSlotNext,p=lp.iSlotPrev; if (n) pL[n].iSlotPrev=p; if (p) pL[p].iSlotNext=n; else anTable[lp.nSlot]=n; };

*Thanks Dave Terracino

(fixed in 10.1)

When I upgraded to CMarkup 10, I ran a small benchmark program that does basic XML writing and reading. Unfortunately CMarkup 10 is slower than revision 9 when writing XML files. There also seems to be a scaling problem:

CMarkup 9  10000 Runs 381ms,       100000 Runs 2814ms
CMarkup 10 10000 Runs 711ms (!),   100000 Runs 38635ms (> 10 times slower!)

[sorry, this is a bug only for generating documents with MFC CString (not STL string), noticeable when generating documents over 100k, which you can fix by removing +n/100 in 2 places in Markup.h, (fixed in 10.1) read more...]

(fixed in 10.0)

IBM Rational Purify and Boundschecker may complain that nTagLengths is not initialized before it is used in void SetStartTagLen( int n ) { nTagLengths = (nTagLengths & ~EP_STMASK) + n; };. This is caused by the way tag lengths were implemented in the struct ElemPos nTagLengths member since Release 7.0. It is not actually utilizing uninitialized bits, but the memory checkers might not know that. Bit fields alleviate this confusion and they will be used in the next release, but in the meantime you can fix it yourself as shown below. In addition, EP_STMASK is 0x2fffff instead of 0x3fffff causing a problem with start tag lengths over a megabyte (should support 4MB start tags meaning unusually large attributes). The bit fields implementation is more self-evident and less prone to bugs.

Fix for 7.0 to 9.0: The changes are only in Markup.h in struct ElemPos. First replace the following methods:

int StartTagLen() const { return nStartTagLen; };
void SetStartTagLen( int n ) { nStartTagLen = n; };
void AdjustStartTagLen( int n ) { nStartTagLen += n; };
int EndTagLen() const { return nEndTagLen; };
void SetEndTagLen( int n ) { nEndTagLen = n; };

Then a few lines below, replace the int nTagLengths declaration with these two:

unsigned int nStartTagLen : 22; // 4MB limit for start tag
unsigned int nEndTagLen : 10; // 1K limit for end tag

(fixed in 8.3)

A report of a crash caused by using the firstobject XML editor tree customization feature with Unicode text turned up an underlying bug in releases 7.0 to 8.2 of CMarkup (MFC) and CMarkupSTL (STL). A non-ASCII character name in SavePos and RestorePos will cause a GPF.

Fix: In struct SavedPosMap in Markup.h or MarkupSTL.h, change the Hash function to read as follows (changes shown in bold):

int Hash( LPCTSTR szName ) { unsigned int n=0;
  while (*szName) n += (unsigned int)(*szName++); return n % SPM_SIZE; };

My XML document is suddenly not being accepted in release 7.2 due to an attribute containing an apostrophe.

Whenever a CMarkup object is assigned the value of an empty CMarkup document there is heap corruption (which can be detected in MFC with AfxCheckMemory() after calling AddElem). There is no problem if the CMarkup object on the right hand side contains any elements, so this is a somewhat rare situation. The case that was reported was using xml = CMarkup(); to empty out the xml CMarkup object, but xml.SetDoc(NULL) is a more direct way to do that.

CMarkup seems to lose track of elements after RemoveElem since upgrade to release 7.0.

When upgrading to CMarkup 7.0, after AddChildSubDoc with the following element as a subdocument:

<analysis_name>Analysis</analysis_name>

Debugging shows that GetChildTagName == "analysis_name" so GetChildData SHOULD == "Analysis" but it is returning "" instead. It thinks it is an empty element due to a bug in AddChildSubDoc.

Tagnames like "_Example" produce an error on parsing xml files.

(fixed in 7.0)

Release 6.6 introduced an extra comma in the error string. After calling SetDoc( strXML ) with ill-formed XML, the result of GetError() has a comma at the beginning. This bug only exists in Release 6.6.

Fix: The change is in the x_ParseDoc() function where there is a 4 line if else clause after the remark that says Combine preserved result with parse error. Add the following if statement and curly brackets around the whole if else clause; in the MFC version Markup.cpp use:

if ( ! csResult.IsEmpty() )
{
   if ... else ...
}

In the STL version MarkupSTL.cpp use:

if ( strResult.size() )
{
   if ... else ...
}

The leak in SetDoc() and x_AddSubDoc() is still in 6.5. ...in our services applications it ended up loosing a pointer to a copy of a BSTR the size of a whole XML document we were loading from a string.

The internal x_TextToDoc function fails to support double-byte characters. This failure occurs when MBCS is defined for the build and you add double-byte characters to your document (i.e. it does not occur in regular ASCII or UTF-8). For example, if the paramater szText is 3 GB2312 Chinese characters (hex D6 D0 B9 FA C8 CB) or 6 bytes, after the loop csText is only 3 bytes (hex D6 B9 C8).

I have discovered what appears to be a bug in x_AddSubDoc (called from AddSubDoc, InsertSubDoc, AddChildSubDoc and InsertChildSubDoc). If the document to be added or inserted to the parent document contains a processing instruction such as: <?xml version="1.0"?> then the software gets stuck inside an infinite loop within x_AddSubDoc. The problem code appears to be the loop:

// Skip version tag or DTD at start of subdocument
TokenPos token( szSubDoc );
int nNodeType = x_ParseNode( token );
while ( nNodeType && nNodeType != MNT_ELEMENT )
{
token.szDoc = &szSubDoc[token.nNext];
token.nNext = 0;
nNodeType = x_ParseNode( token );
}

DecodeBase64 is not working in the Windows CE (UNICODE build) of CMarkup.

If I look for a child element using FindChildElem("/root/list/thing"), I find the right element. The main position is moved to list, and the child position to thing. The level counter doesn't change though:

m_Doc.ResetPos();
m_Doc.FindChildElem("/root/list/thing");
// main pos is list, child pos is thing, level is 0!
// if I then try to navigate out
m_Doc.OutOfElem();
// I can't, because we are already at level 0

Bug: everywhere you use CFileException * don't forget to delete it. That will fix memory leak caused by the exception not being deleted.

catch (CFileException*e)
{
  e->Delete();
  return FALSE;
}

First, Exceptions are not supported under WinCE (File Handling) and second, two Macros do not exist under CE (_tclen, _tccpy)