JFile.cpp: JFile and MFile both "virtual public MString" a single shared
base, so a virtual base is initialized only by the *most derived* class's
constructor. JFile's own constructor never mentions MString, so
JString's own "{}" default initializer never ran - a JFile backed by a
new or nonexistent file started as a raw empty string instead of a valid
empty JSON object. Every subsequent locate()/set() call then silently
misbehaved (no leading "{" for ifNext("{") to match, so writes landed at
offset 0 with no braces or separators - fields ended up prepended in
reverse order, concatenated with no delimiters at all). Fixed by seeding
"{}" via append (matching MFile's own load pattern) whenever the loaded
content is empty.
MString.cpp: several ZString-source copy paths (the ZString/MString copy
constructors, both assignment operators, operator<<(ZString), insert(),
write()) called zstring.getData() (the object's absolute start) paired
with zstring.getLength() (which is documented/implemented as "remaining
bytes from cursor to end", i.e. length - (cursor - data)). Pairing an
absolute start with a cursor-relative length silently corrupts any
cursor-advanced source: the copy starts from the wrong (too-early)
position but is truncated by exactly the amount the cursor had already
advanced, keeping unwanted leading bytes while dropping trailing ones.
Found via the CGIFormData-style resumability testing pattern used
elsewhere this session, triggered by JetCore's new "@name" session
variable feature stripping a sigil prefix via ifNext() before streaming
the remainder into an MString. Fixed by pairing zstring.getCursor()
(cursor-relative start) with zstring.getLength() consistently everywhere
this pattern appeared.
Verified via the existing jstring_test/mstring_test/zstring_test/
parser_test suites (all pass, no output changes) plus a new isolated
JFile round-trip test proving persistence across two separate process
instances sharing one file.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- CGIFormData: fix broken setSize()+read() double-length bug that
corrupted every parsed body with a leading run of garbage bytes
(setSize(contentLength) pre-set length before read()/write()
appended on top of it); switch content-type checks from exact
equality to startsWith() since a real multipart Content-Type
always carries a boundary= parameter; implement the previously
empty multipart/form-data branch (ordinary fields only, file
uploads deferred to a separate upload mechanism per TODO.txt);
restore operator[] real lookup logic (was hardcoded to echo the
key back); default-initialize formdata to NULL; fix mismatched
include guard (leftover from an IMFFormData.h copy-paste); drop
the unused IMFHeader.h include that pulled in a broken,
unrelated StreamReader.h dependency.
- CGIFormattedData: parameterize the split delimiter (was hardcoded
to &, which silently broke cookie parsing since HTTP_COOKIE uses
; not &) and trim whitespace on each split token.
- MString::toCGI()/fromCGI(): were unimplemented stubs (always
returned an empty string); implemented proper CGI percent-encode
/ percent-decode + space plus-encoding, and fixed the one caller
that discarded fromCGIs return value instead of using it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The Exception on the odd-length-input path was constructed but never
thrown (missing throw keyword) - the temporary was destroyed with no
effect, so execution fell through to an out-of-bounds nextChar() read
past the exhausted buffer instead of raising an error. Added the
missing throw.
Verified via full local compile: MString.cpp builds clean standalone;
a full-repo pass shows only the pre-existing, already-known
StreamReader.h-missing failures (7 files, unrelated to this change),
confirmed via each error log individually.
