https://oss-fuzz.com/testcase-detail/5964400971874304
The original upng code this is based on just sizes the temp buffers for 15,
but the trees can come in 19, 32, or 288 lengths. Set the buffer sizes for
the worst case.
Add some asserts to help catch any further problems more directly.
Add a dlo-based layout callback for use with lhp.
If lhp_dl_render() is used as the Lws Html/CSS parser callback, it
produces a display_list representation of the Html as DLOs, referencing the
appropriate CSS to drive the layout as best it can.
The display list can be rasterized on to an lws_display using the display's
state object
lds->disp->blit(lds, (uint8_t *)&dl, &box);
Introduce a very lightweight html5 + css2.1+ stateful stream parser, along
the same lines as the lws json and cbor ones.
This is interesting primarily because of just how low-resource it is for
modest css + html, it uses an lwsac to hold the entirity of the css in
memory at once but the html is parsed in chunks without any need to keep
previous chunks around (chunks may be as small as 1 byte).
A user callback receives element entry and exit callbacks with payload and
all attributes parsed out, CSS related to the active element stack is
parsed to provide a list of active css attributes, which takes heap for the
duration of the parsing.
In effect this provides rich information about the html and css state to
the callback, which has the job of producing the layout in a user-defined
way.
As such, there is no DOM in memory at one time, there is only a stack of
active elements like <html><body><div>xxx with their associated attributes
(like class). So as it is, it does not support DOM modification such as
JS changing elements after parsing, although elements with interesting IDs
could be kept around by the callback. There is a corresponding tiny and
relatively flat heap usage regardless of html size.
Default CSS is specified as recommended in the CSS 2.1 standard.
Inline <style></style> elements are supported, but not pre-html5 style= in
element attributes, since these are incompatible with strict CSP.
What the attributes should mean on your system, eg, font-size, font-family
etc is left for the user callback to decide, along with how to lay out the
items using the CSS attributes, and render them.
Fixed point 32.32 constants are used (fraction expressed at parts in 100M)
instead of floating point.
If you have presentation needs, even on a constrained display on a
constrained microcontroller, this makes it feasible to use standardized
markup and styling instead of roll your own.
This adds an optional lws VFS layer that exposes the named dlo object
registry. So you can register a blob like a JPG named "my.jpg", and
access it on the vfs as, eg, /dlofs/my.jpg (or file:///dlofs/my.jpg
if using the SS file:// support for VFS namespace).
This adds optional display list support to lws_display, using DLOs (Display
List Objects). DLOs for rectangle / rounded rectangle (with circle as the
degenerate case), PNGs, JPEG and compressed, antialiased bitmapped fonts
and text primitives are provided.
Logical DLOs are instantiated on heap and listed into an lws_display_list
owner, DLOs handle attributes like position, bounding box, colour +
opacity, and local error diffusion backing buffer.
When the display list is complete, it can be rasterized a line at a time,
with scoped error diffusion resolved, such that no allocation for the
framebuffer is required at any point. DLOs are freed as the rasterization
moves beyond their bounding box.
Adds a platform registry binding names and other metadata to lws_display
fonts / PNGs / JPEGs. Provides registration, destruction and best match
selection apis.
Introduce a rewritten picojpeg that is able to operate statefully and
rasterize into an internal line ringbuffer, emitting a line of pixels
at a time to the caller. This is the JPEG equivalent of the lws
PNG decoder.
JPEG is based around 8- or 16- line height MCU blocks, depending on
the chroma coding, mandating a corresponding internal line buffer
requirement.
Example total heap requirement for various kinds of 600px width jpeg
decoding:
Grayscale: 6.5KB
RGB 4:4:4: 16.4KB
RGB 4:2:2v: 16.4KB
RGB 4:4:2h: 31KB
RGB 4:4:0: 31KB
No other allocations occur during decode.
Stateful stream parsing means decode can be paused for lack of input
at any time and resumed seamlessly when more input becomes available.
The adapted upng has a very compact fully-stateful lws-aligned
implementation already.
Adapt it to also be buildable and operable standalone, and to
understand gzip headers.
Provide some apis to inflate gzip simply reusing opaque inflator
contexts from upng.
Provide an api test that inflates gzip files from stdin -> stdout
Add a rewritten version of upng that decodes statefully line by line, and so
does not require a bitmap buffer for the output. This compares to original
upng approach that needs heap allocations for the input, the whole output
and intermediate allocations.
Instead of buffers for input, decompression and output, it only allocates
2 x lines of RGBA pixels (ie, a few KB), and 32KB of decompressed data for
backward references in the decoder, and decodes as needed into the 2-line
buffer to produce line rasterized results. For a 600px width PNG, this is
just 40KB heap for the duration.
This adds apis that enable usage of compressed backtraces in heap
instrumentation.
A decompressor tool is also provided that emits a textual
call stack suitable for use with addr2line.
This allows handling of the unusal but foreseeable situation were
the client provides a zero length output buffer, for example, if
the input buffer was also zero length.
Leave the http minilex as it is, and add an improved version in lib/misc
- get a list of strings from stdin and emit C header to stdout
- support ambiguous terminals (xxx and xxx-something) correctly regardless
of introduction order
- add generic parser in lib/misc
minilex doesn't build as part of lws since it's only needed by developers,
there's a one-line build documented at a comment at the top of
lib/misc/minilex.c
For plugins that handle PROTOCOL_INIT, we have to iterate any PLUGINS_BUILTIN
plugins as if we had just discovered and loaded them from plugin files, so
they bind to vhosts appropriately.
Add some private helpers to keep the guts from duplication in plat.
This adds an optional feature LEJP_FLAG_FEAT_OBJECT_INDEXES that changes
lejp to treat { } items as indexable in ctx->i[] / ctx->ipos, since they
also can take commas.
This may break existing uses so it requires the default-off feature flag to
enable it. The flags context field is zeroed by lejp_construct(), so any
flags should be set on ctx->flags after alling that.
There's also a flag LEJP_FLAG_LATEST available as an alias to enable any
desirable but not-backwards-compatible behaviour, including this.
Add the info to the README and adapt the unit test to do it both with and
without the FEAT_OBJECT_INDEXES flag.
This is a NOP for existing usecases.
At the moment the only implemented transport for serialized SS is wsi, it's
typically used with Unix Domain Sockets, but it also works over tcp the
same.
It generalizes the interface between serialized chunks and the
transport, separately for client and proxy. The wsi transport is migrated
to use the new transport ops structs.
It will then be possible to "bring your own transport", so long as it is
reliable, and in-order, both for proxy and client / sspc.
We also adapt minimal-secure-streams-binance to build the -client variant
via SS proxy as well.
LWS_ONLY_SSPC is added so libwebsockets can be produced with just sspc
client support even for tiny targets.
A new embedded minimal example for rpi pico is also provided that
demonstrates using Serialized SS over a UART to an SS proxy, to implement
the SS Binance example on the pico, even though it has no networking itself.
This provides very memory-efficient CBOR stream parsing
and writing.
The parser converts pieces of CBOR into callbacks that define
the structure and collate string and blobs into buffer chunks
for extensible and easy access.
It is fragementation-safe and does not need all the CBOR in
the same place at one time, chunks of CBOR are parsed and
discarded as provided.
It does not allocate and just needs a few hundred bytes of
stack for even huge CBOR objects. Huge strings and blobs
are handled without needing memory to hold them atomically.
Includes ./minimal-examples/api-tests/api-test-lecp that
unit tests it against 82 official example CBORs and
26 additional test vectors from COSE (just checking the CBOR
parsing).
The writing apis allow printf style semantics with a variety
of CBOR-aware %-formats. The apis write into a context that
manages output buffer usage, if the output buffer fills,
then the apis return with an AGAIN code that lets you issue
and reset the output buffer and repeat the api all to issue
more output. The subsequent calls can occur much later or
from a different function context, so this is perfect for
WRITEABLE-mediated output from the network parts of lws.
See ./READMEs/README.cbor-lecp.md
Also prioritize LD_LIBRARY_PATH check for plugins first
Iterate through paths in LD_LIBRARY_PATH in order
Warn on failed plugins init but continue protocol init
This is a huge patch that should be a global NOP.
For unix type platforms it enables -Wconversion to issue warnings (-> error)
for all automatic casts that seem less than ideal but are normally concealed
by the toolchain.
This is things like passing an int to a size_t argument. Once enabled, I
went through all args on my default build (which build most things) and
tried to make the removed default cast explicit.
With that approach it neither change nor bloat the code, since it compiles
to whatever it was doing before, just with the casts made explicit... in a
few cases I changed some length args from int to size_t but largely left
the causes alone.
From now on, new code that is relying on less than ideal casting
will complain and nudge me to improve it by warnings.
On an error path, we might not have a valid spa / lejp to destroy.
In that case, don't hurl ourselves into calling a
function pointer that can be NULL for the destroy cb.
This adds some new objects and helpers for keeping and logging
info on grouped allocations, a group is, eg, SS handles or client
wsis.
Allocated objects get a context-unique "tag" string intended to replace
%p / wsi pointers etc. Pointers quickly become confusing when
allocations are freed and reused, the tag string won't repeat
until you produce 2^64 objects in a context.
In addition the tag string documents the object group, with prefixes
like "wsi-" or "vh-" and contain object-specific additional
information like the vhost name, address / port or the role of the wsi.
At creation time the lws code can use a format string and args
to add whatever group-specific info makes sense, eg, a wsi bound
to a secure stream can also append the guid of the secure stream,
it's copied into the new object tag and so is still available
cleanly after the stream is destroyed if the wsi outlives it.
C++ APIs wrapping SS client
These are intended to provide an experimental protocol-independent c++
api even more abstracted than secure streams, along the lines of
"wget -Omyfile https://example.com/thing"
WIP
