Brad ArantandClaude Sonnet 5
3e6e410fe8
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>
24 lines
901 B
C++
24 lines
901 B
C++
#include "JFile.h"
|
|
#include "ZString.h"
|
|
#include "Exception.h"
|
|
|
|
namespace coreutils {
|
|
|
|
// MFile and JString share a single virtual MString base (the diamond:
|
|
// both "MFile : virtual public MString" and "JString : virtual public
|
|
// MString"), and a virtual base is initialized only by the *most
|
|
// derived* class's constructor - so JString's own "{}" default
|
|
// initializer never runs here. Left alone, a JFile backed by a new or
|
|
// empty file starts as a raw empty string instead of a valid empty JSON
|
|
// object, and every subsequent locate()/set() call silently misbehaves
|
|
// (no leading "{" for ifNext("{") to match, so writes end up inserted
|
|
// at offset 0 with no braces or separators at all). Detect that case
|
|
// here and seed valid JSON explicitly.
|
|
JFile::JFile(ZString filename) : MFile(filename) {
|
|
if(getLength() == 0)
|
|
*this << "{}";
|
|
}
|
|
|
|
|
|
}
|