I found a regression between libredwg 0.13.3.7545 and 0.13.3.7850 when using the latest release on Windows with Visual Studio.

[kgddqypm]

✔ Version 0.13.3.7545
Debug build → DWG reading OK
Release build → DWG reading OK

❌ Version 0.13.3.7850
Debug build → DWG reading OK
Release build → DWG reading NOT correct

7545&7550
DWG Version:ACAD2000
Writing DWG produces a file that AutoCAD reports as “The drawing file is corrupted and needs recovery
After debugging the internal structure of the DWG:
hdr->last_entity becomes empty or incorrect after adding a new entity

This matches the known issues in #1105 about incomplete update of entity chain and block ownership links.

dwg_add_LINE(hdr, &pt1, &pt2);

Thank you very much for your work on libredwg. It is an excellent project and extremely valuable for DWG interoperability.

[kgddqypm]

DWG 2000 (AC1015): works correctly
DWG 2007 (AC1021): works correctly
DWG 2004 (AC1018): data is only partially read in release (no crash)

[michal-josef-spacek]

Do you reproduce this situation e.g. by dwgadd?
With content e.g.:

line (0 0 0) (10 10 0)

[kgddqypm]

@michal-josef-spacek Hi~ michal-josef-spacek

1. R2004.zip
   version:libredwg-0.13.3.7851
   use release num_objects count 166
   user debug num_objects count 2684

2. common.c
   strcasecmp Error in judgment, resulting in the inability to find the correct block when searching for a block. Should we return three values, 0, 1, -1.

EXPORT int
strcasecmp (const char *a, const char *b)
{
  size_t l2;
  int r1 = strcmp (a, b);
  if (!r1)
    return 0;
  l2 = strlen (b);
  for (size_t i = 0; i < strlen (a); i++)
    {
      if (i > l2)
        return 1;
      if (toupper (a[i]) != toupper (b[i]))
        //The following judgment should return three values -1,1 instead of 0 and 1
        // -->
        //return toupper (a[i]) < toupper (b[i]);
        return toupper (a[i]) < toupper (b[i]) ? -1 : 1;
        // <--
    }
  return 0;
}

3. add code

    Dwg_Data dwgDstIO;
    memset(&dwgDstIO, 0, sizeof(Dwg_Data));
    int nRet = dwg_read_file("d:/R2000.dwg", &dwgDstIO);

    if (nRet >= DWG_ERR_CRITICAL)
    {
        dwg_free(&dwgDstIO);
        return;
    }
    
    Dwg_Object *mspace = dwg_model_space_object(&dwgDstIO);
    Dwg_Object_Ref *mspace_ref = dwg_model_space_ref(&dwgDstIO);
    Dwg_Object_BLOCK_HEADER *hdr = mspace->tio.object->tio.BLOCK_HEADER;

    dwg_point_3d pt1 = { 0.0, 0.0, 0.0 };
    dwg_point_3d pt2 = { 100.0, 100.0, 0.0 };
    Dwg_Entity_LINE *pLine = dwg_add_LINE(hdr, &pt1, &pt2);

    nRet = dwg_write_file("d:/R2000_Write.dwg", &dwgDstIO);

    dwg_free(&dwgDstIO);

R2000.zip

[michal-josef-spacek]

@kgddqypm I check, that libredwg own implementation of strcasecmp is bad, created issue to fix (#1207).

Is this issue related to the implementation of strcasecmp or not?

I don't understand why is difference between debug and release modes. I tested mingw build on Linux and seems ok (num_objects value).

[kgddqypm]

@michal-josef-spacek

I am still puzzled by the difference between Debug and Release behavior in newer versions.

Debug works correctly, but Release shows incorrect or incomplete data.
I suspect this may be related to compiler optimizations, structure alignment, or version-specific changes,
but I am not familiar enough with the internal code to locate the exact cause.

I am still search and will update if I find more information.

[michal-josef-spacek]

@kgddqypm One thing, which could be useful is bisect the issue commit between commits you are described.

[kgddqypm]

@michal-josef-spacek
thank you very much for the bisect , it’s very helpful and makes the decompression logic much clearer.

I’ve been debugging a DWG R2004 read issue on Windows (32-bit), and after running git bisect and multiple tests, it looks like the problem is introduced in commit c2b3173 (refactor 2004 decompression).

c2b317322f377e5f3b9656a12bd2c4af8ed53311 is the first bad commit
commit c2b317322f377e5f3b9656a12bd2c4af8ed53311
Author: Reini Urban <reini.urban@gmail.com>
Date:   Sun Mar 23 16:54:16 2025 +0100

    refactor 2004 decompression

    See GH #439 for the decompression bug analysis.
    Simplify to use our bit chains

 src/decode.c | 490 +++++++++++++++++++++++++++++------------------------------
 1 file changed, 240 insertions(+), 250 deletions(-)

[rurban]

@michal-josef-spacek

I am still puzzled by the difference between Debug and Release behavior in newer versions.

Debug works correctly, but Release shows incorrect or incomplete data. I suspect this may be related to compiler optimizations, structure alignment, or version-specific changes, but I am not familiar enough with the internal code to locate the exact cause.

I am still search and will update if I find more information.

That's one bad memmove in Release mode I haven't come around to analyse yet. There's a ticket for it