Fuzzer: Each read/write produces 2 bytes bigger file

[qarmin]

use std::error::Error;
use std::process::ExitCode;

static NON_ASCII_IMPLEMENTATION_CLASS_UID: &[u8] =
    include_bytes!("../inputs/non-ascii-implementation-class-uid.bin");

fn run(data: &[u8]) -> Result<(), Box<dyn Error>> {
    let obj = dicom_object::OpenFileOptions::new()
        .read_preamble(dicom_object::file::ReadPreamble::Auto)
        .odd_length_strategy(dicom_object::file::OddLengthStrategy::Fail)
        .from_reader(data)?;

    let mut bytes = Vec::new();
    obj.write_all(&mut bytes)?;

    let obj2 = dicom_object::from_reader(bytes.as_slice())?;
    let mut bytes2 = Vec::new();
    obj2.write_all(&mut bytes2)?;

    if bytes != bytes2 {
        return Err(format!(
            "second write is not byte-identical to the first write: {} vs {} bytes",
            bytes.len(),
            bytes2.len()
        )
        .into());
    }
    Ok(())
}

fn main() -> ExitCode {
    match run(NON_ASCII_IMPLEMENTATION_CLASS_UID) {
        Ok(()) => {
            println!("REPRO-OK");
            ExitCode::SUCCESS
        }
        Err(e) => {
            println!("REPRO-BROKEN: {e}");
            ExitCode::FAILURE
        }
    }
}

dump of content

non-ascii-implementation-class-uid.bin: 
Media Storage SOP Class UID: 1.2.840.10008.5.1.4.1.1.7 (Secondary Capture Image Storage)
Media Storage SOP Instance UID: 1.2.3.4.5.6.7.8.9.0
Transfer Syntax: 1.2.840.10008.1.2.1 (Explicit VR Little Endian)
Implementation Class UID: 1.2.40.0.13.1.3ö

causes this

REPRO-BROKEN: second write is not byte-identical to the first write: 276 vs 278 bytes

non-ascii-implementation-class-uid.bin.zip

diff --git a/object/src/meta.rs b/object/src/meta.rs
index b3546f01..eac89066 100644
--- a/object/src/meta.rs
+++ b/object/src/meta.rs
@@ -1246,7 +1246,12 @@ where
     T: Into<String>,
 {
     let mut s = s.into();
-    if s.len() % 2 == 1 {
+    if s.chars().count() % 2 == 1 {
         s.push(pad);
     }
     s

seems to fix issue

[Enet4]

The root issue seems to be with having admitted a UID with an improper character. At this level I would prefer to outright reject any UID value with characters outside the default repertoire. With this we would not need to consider the round-trip.

In turn, I don't think that the suggested patch would be acceptable anyway: for value padding to even length, the length is determined in bytes, not in number of characters. It just happens that a poorly encoded text value is not guaranteed be encoded back to the same length.

[imanabu]

The DICOM Standard on the UID is strict on this. Anything do not adhere to the UID rule should be rejected, and cause an exception.