[gdal-dev] Trailing null in XML metadata in GMLJP2

[Even Rouault]

Hi Brad,

yes you're right. A 19-year old bug now gone in 
https://github.com/OSGeo/gdal/pull/13450. Perhaps the erroneous addition 
of the NUL byte was to imitate oldish Kakadu version since the jpylyzer 
manual mentions that about their 'nullbyte' option?

Even

Le 20/11/2025 à 01:56, Brad Hards via gdal-dev a écrit :
>
> It looks like there is a trailing null in the character data written 
> inside the XML box in JPEG 2000 (only tested with OpenJPEG).
>
>
> I'm seeing a validation error in jpylyzer about not well formed XML, 
> which I think is probably related to this. Or at least goes away with 
> this change:
>
>
> *diff --git a/gcore/gdaljp2metadata.cpp b/gcore/gdaljp2metadata.cpp*
> *index 439b7e6625..a247cad9f8 100644*
> *--- a/gcore/gdaljp2metadata.cpp*
> *+++ b/gcore/gdaljp2metadata.cpp*
> @@ -3333,7 +3333,7 
> @@GDALJP2Metadata::CreateGDALMultiDomainMetadataXMLBox(GDALDataset 
> *poSrcDS,
>
>     GDALJP2Box *poBox = new GDALJP2Box();
>     poBox->SetType("xml "); - 
>    poBox->SetWritableData(static_cast<int>(strlen(pszXML) + 1),
> +    poBox->SetWritableData(static_cast<int>(strlen(pszXML)),
>                            reinterpret_cast<const GByte *>(pszXML));
>     CPLFree(pszXML);
>
> However that +1 looks deliberate. So is that trailing null 
> intentional, in that its required for some interoperability or 
> backwards compatibility reason, even though it isn't strictly allowed 
> in XML?
>
>
> Brad
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251120/047b0fd3/attachment.htm>