Have we considered an LEB128-like encoding for section string names?

[mbebenita]

Currently, section names are encoded as:

Field	Type	Description
size	varuint32	size of this section in bytes, excluding this size
id_len	varuint32	section identifier string length
id_str	bytes	section identifier string of id_len bytes

We could restrict id_str to 7-bit ASCII and then just use a LEB128-like encoding for the entire string. Might be too much of a cute trick, but would save us a byte in each section header. One could image that the section structure could be nested and used to encode a variety of data in the binary file, so a tiny header might be useful.

Here's another thought - choose names from the brotli dictionary!

Sorry if this is off topic, but in case it's of interest here's how brotli encodes the current section names. where [] are dictionary hits and {} are copy hits.

[memory]
sig[nature]s
[functions]
[global]s
[data]_[segment]{s
function}_[table]
end
[start]_[function]
[import]{_table
e}x{port_table}

Another option would be for the wasm CG to reserve all single character names for it's own use and use single character section names.

[titzer]

That is a neat trick, however the current length+bytes design will match
the other places that strings can occur, e.g. as function names and
import/exports. Those we definitely want to treat as uninterpreted bytes
from the engine point of view, and leave the interpretation up to the
embedder.

On Sat, Feb 27, 2016 at 2:50 AM, JSStats notifications@github.com wrote:

Sorry if this is off topic, but in case it's of interest here's how brotli
encodes the current section names. where [] are dictionary hits and {}
are copy hits.

[memory]
sig[nature]s
[functions]
[global]s
[data][segment]{s
function}[table]
end
[start]_[function]
[import]{_table
e}x{port_table}

Another option would be for the wasm CG to reserve all single character
names for it's own use and use single character section names.

—
Reply to this email directly or view it on GitHub
#561 (comment).

[jfbastien]

Agreed with @titzer, though we should write that rationale down somewhere! We simply don't want .wasm generation to require magical escaping, and wasm really doesn't care about the bytes in there so there's no reason to add extra constraints.

[pizlonator]

It's too late for this.