Should it be valid to have empty Data/Element sections

[saambarati]

Right now, I think it's valid to have zero elem_type in an Element section. Should we allow this?
Ditto for Data.

https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#element-section

[jfbastien]

Pretty much all sections. Code without Code? etc.

[pipcet]

I was surprised that right now, it's illegal to have a zero-table table section if there is a table import, or a zero-memories memory section if there is a memory import. If there is no import, though, zero tables are okay.

I think it would be cleaner to allow those, and zero-element sized sections generally. I don't think that would cost consumers anything, and producers could cut a corner.

(By "sized sections", I mean sections beginning with a count of entries and then containing the entries. Right now, that's all sections but the start section; maybe the start section should have a count (1 in the MVP) as well, for consistency?)

[saambarati]

@pipcet My gut feeling is to go in the opposite direction. It's likely a bug to have zero sized sections of anything that are meaningful only if they have a size. So my vote would be to make zero sized sections an error.

[pipcet]

@saambarati I'm not sure I can think of a common bug that would result in a valid, but zero-sized, section when a valid non-zero-sized section is the intended output. Instead, it seems to me more likely that the case in which there is code but no data or data but no code isn't usually well-tested, and might well result in a zero-sized section.

I think a simple producer should only be expected to fill in a fixed wasm skeleton with its data, rather than conditionalizing part of the skeleton based on whether there is any data. That's what I do for intermediate files, which are produced as binary output by GNU ld (so, in particular, they have a linker map allowing me to trace back file offsets) but should also be valid wasm. (I realize I'm a bit of a special case :-) ).

[rossberg]

I don't see any good reason for introducing all these special cases for zero-sized things. It generally is unnecessary hassle to disallow them, for both producers and consumers. Catching internal problems in producers is not the purpose of validation.

@pipcet, where do you read that zero-sized table sections are illegal in the presence of an import? The spec interpreter makes no such restriction. If that's stated somewhere then it's simply an oversight and should be corrected (probably a left-over from the pre-multi-table design?).

[saambarati]

@rossberg-chromium I think it's inevitably something that needs to be thought about. Would an elem_segment of zero count but an offset that would be beyond the table's size cause a RangeError during instantiation? If not, the text that talks about RangeErrors needs to be very specific about how it does its checks. If it is an error, again, this text needs to be very specific about how it does its checks.

[rossberg]

You seem to be assuming it hasn't been thought about yet. :) There are tests for it in the test suite.

But I agree for the specific case you mention, that's the corner case I pointed out in my earlier comment: #897 (comment)
I agree that this one requires a choice, and I'm happy to revisit the current spec's choice.

[pipcet]

@rossberg-chromium Module.md says:

In the MVP, every table is a default table and thus there may be at most one table import or table section

(and equivalently for tables). SpiderMonkey implements this faithfully and complains about a zero-sized table section in the presence of an import.

Even if that restriction is to remain, the "thus" doesn't make sense. You're right that what's probably intended is "... or table definition". (Note that each sentence occurs twice for a total of four places that need changing).

[rossberg]

@pipcet, thanks, yes, this looks very much like an oversight. It wasn't adapted when we moved from single table sections to multi-table sections. I'll create a PR.

[jfbastien]

Since we're doing something about zero-sized things already, I would rather do that something up-front, at validation time.

[rossberg]

@jfbastien, we never need to do anything specific for zero-sized things, it always falls out naturally from the general rules. That includes the specific case mentioned above. However, in that case the behaviour depends on what general validation criterion we choose for segment bounds.

There are basically two choices for that one:

1. Require that the segment end is no larger than the size of the memory/table.
2. Check that no write occurs out of bounds.

The former probably fits better with a priori bounds checking of segments (as currently specified in JS.md), while the latter fits better with the change you proposed. The zero-size case follows from there.

[pipcet]

@rossberg-chromium If we were to go with choice 1, what would be a safe address to use for a dynamic loader assigning a new module's zero-sized data segment's base address?

I'm assuming NULL pointers might one day be made invalid, so it's not 0. It's not "the end of memory" either, unless you're willing to guarantee that memory won't ever be allowed to shrink. The best I can come up with is that the dynamic loader would use its own data base address, which goes wrong if the dynamic loader itself doesn't have a data segment.

So, IMHO, choice 2 sounds much safer, even though it's arguably a special case for zero-sized things.

[rossberg]

@pipcet, hm, not sure I understand your scenario. How is the zero case different (more difficult even?) from the non-zero case? What strategy do you envision for the general case that doesn't work for zero?

It's unclear to me how null pointers relate, but note that there actually is no such thing in Wasm. That's a detail of compiling certain languages to it, nothing built in, so nothing we can make illegal either. (And strictly speaking, not even C requires representing null pointers with the value 0.)

[pipcet]

@rossberg-chromium In the general case, the dynamic loader would presumably just use malloc(size). If size is 0, that might not be a valid pointer (as you point out, it might be NULL but not LMA 0, or it might be NULL at LMA 0 and there might be a future extension to unmap LMA 0, or it might be an invalid pointer by implementation of malloc, which free recognizes as such and ignores).

So malloc doesn't work, though you could argue that's because malloc is a bit wonky. But if we posit shrinkable memory, sbrk(size) might also become invalid (perhaps the dynamic loader calls free unrelatedly, free recognizes the last block before the brk belongs to the malloc implementation and shrinks memory). malloc(size ? size : 1) would work, but that would be requiring the dynamic loader to special-case the zero case.

(The NULL pointer issue is tangential, but making NULL invalid (while keeping it at LMA 0) is definitely on my post-MVP wishlist. I'm not proposing to handle LMA 0 differently from other addresses, of course, just that there be an option to unmap certain address ranges that C could use to unmap LMA 0, while other languages would presumably have no need of that.)

In summary, I think there are conceivable (though possibly ill-conceived) post-MVP extensions that would break things with choice 1 but work just fine with choice 2, so choice 2 gives us more options for future decisions.