do_source_file: Parsing: sha1.c as language C
parse_cleanup(479): pc orig line is 257, orig col is 33, Text() is '}', type is BRACE_CLOSE
parse_cleanup(485): (frm.top().type + 1) is VBRACE_CLOSE
parse_cleanup(492): File: sha1.c, orig line is 257, orig col is 33, Error: Unexpected '}' for 'VBRACE_OPEN', which was on line 256

Causing uncrustify (0.80) to assert:

do_source_file: Parsing: execmisc.cpp as language CPP
parse_cleanup(479): pc orig line is 1257, orig col is 55, Text() is ')', type is PAREN_CLOSE
parse_cleanup(485): (frm.top().type + 1) is SQUARE_CLOSE
parse_cleanup(492): File: execmisc.cpp, orig line is 1257, orig col is 55, Error: Unexpected ')' for 'SQUARE_OPEN', which was on line 1257

Uncrustify-0.80.1-47-ba7fc1679

Some of these likely break WinCE support.

That *is* the write lock!

Don't go digging around in the filesystem when you don't have to.

Some Coverity issues, some deadlocks, some crashes...
Just misc stuff.

Also, we can now use a read lock.

(e.g. new user)

Similar bug fix as that just made to system.datestr()

Actually use the return value of datestr()

Fixes issue reported by Deuce, regression introduced in commit 490e86fa

"Scan for New Files since Never" is gibberish.

To fix jsdoor build

Helpful for scripts that want to know what file types (extensions) are
supported by the Archive class object.

Still need to work out the JSDOC support for this. Similar to the
Socket class object properties, this will have no documentation/description.

We need to set the "has pixels set" flag in both vmem and in the
bitmap_drawn array to prevent the update from erasing the pixels.

This is likely what the duplicated line was originally, then it got
broken when I switched to the vmem_cell_*() functions.

DDMsgReader: %% should be used with printf() to show a percent sign.  "% " seemed to be showing <error> in some cases (but not always)

See merge request !491

DDMsgReader: %% should be used with printf() to show a percent sign.  "% " seemed to be showing <error> in some cases (but not always)

We're building these one byte at a time, we know the length.
1.98s

For now we're still using strlen, but we can avoid the call for
the common case of zero-length returns.

2.1 seconds.

This should avoid angering Coverity.

Also, no, Coverity still doesn't know from recursive mutexes.