Given the last government shutdown being 34 days & Trump's desire to be remembered, it'll probably extend past the MCM, beyond 34 days.  They'll announce an official cancellation in the next 2 weeks, since there would be no way to change course within 7 days.  Given the price of getting in, the number of volunteers, the 250th anniversary of the marines, it doesn't seem fair to depend on the government's shutdown.  Either way, the museums aren't going to happen.  That might take a drive from FL.

In a parallel universe, a lion got 2 more walnut crushers in after Sep 22 before tapering in just the last 2 weeks.  In reality, the injuries never recovered enough to do any more.  There was instead a focus on 12 milers at race pace, alternating between walking days.

If there is a refund for travel costs, it would have to be a significant amount to be worth it.  Otherwise, lions would just go & run the empty course with a bag full of batteries.  Unlikely to be any refund within 7 days.

The Napa marathon was already looking like a better contender for 4 hours.  It descends 300ft.  Then the bucket list was the LA marathon with another 300ft drop. The methusela of PR's would be the St George with a 2500ft drop.  If a lion can't beat 4 hours in that, he's dead.

There could be a Utah valley rematch, with 1500ft drop.


--------------------------------------------------------------------------------------

Anyways, after mangling the format window, the decision was made to finally convert FileXML & Keyframe to std::string buffers.  Well, they still have a lot of unsafe char string[BCTEXTLEN] buffers, but it's another step.  An awful lot of things had to change to get just those 2 std::string buffers & undoubtedly broke.  1 trick used extensively is sharing the std::string in a keyframe with a FileXML object to avoid copying memory.  

 Keyframes always had a maximum length of 4096 bytes.  There was a constant concern a very long titler sequence would overflow that buffer. 

It takes a diabolical hack to read a file into a std::string.  The STL is intended to be used only with iostream classes, but lions prefer stdio.  This requires a hack which dereferences the string's internal buffer with &text[0].  You have to allocate & set the length before filling the buffer.  1 or both of the reserve & resize calls reallocates the string buffer.  It's not deterministic which one does it.

Neither is it known if reserve adds 1 for the null terminator.  The value of resize is presumably the value of length(), not including the 0.

The problem with iostream is it doesn't support all the file descriptor functions.  There's no access to file numbers, raw devices, buffering control, blocking control, append mode, truncate mode, overwrite mode, read/write mode, terminal modes, serial port modes.  There are no sockets, pipes or FIFOs, so you still have to go back to file descriptor handling or additional libraries instead of 1 common library.

Anyways, bugs come in waves.  The FileXML change introduced a big wave of bugs & exposed others.  It previously filled all strings with [j] = ;  Now that std::string uses push_back() a lot of strings are ending up concatenating instead of replacing.  You have to call clear() before filling the strings.

Likewise, anything that calls set_shared_string for writing needs to call clear().  It automatically sets the read offset to 0 but can't set the write offset without clearing.  It might benefit from an argument specifying write mode.  Otherwise all the FileXML commands which append could be flagged to clear before the 1st write.

-------------------------------------------------------------------------------------------------------------------












Comments

Popular posts from this blog

snow white