JeanHeyd Meneide via Gcc <gcc@gcc.gnu.org> writes:
[...]
> While the following 2 invocation of `#embed` are identical and produce
> exactly the same data:
>
> -----
> #embed <data.bin> clang::offset(1) limit(3) /* ONE */
> #embed <data.bin> limit(3) clang::offset(1) /* TWO */
> -----
>
> some people questioned whether or not the difference in order might
> make some people confused that they do not produce identical effects
> (e.g., that `offset` is always calculated first based on the raw file
> size, and then `limit` is applied after, or vice-versa).
[...]
> Following from the background, some people advocated for providing a
> warning/error for if it was written in the "wrong order". That is,
> since `limit` always applies after `offset`, the standard wanted to
> mandate that such parameters must always be written in a specific
> order. That is, `/* ONE */` would be fine but `/* TWO */` should
> trigger an error.
>
> It was then pointed out that this can also apply to other parameters
> based on the standard wording. For example, `limit(0)` or
> `offset(SIZE_MAX)` can make a resource that has data be considered
> "empty". In particular, using `<data.bin>` again:
>
> -----
> #embed <data.bin> limit(0) if_empty("meow") /* THREE */
> #embed <data.bin> if_empty("meow") limit(0) /* FOUR */
> -----
>
> `/* FOUR */`, under the previous ideals, should issue a diagnostic
> since `if_empty` is being evaluated before `limit` turns the resource
> empty, while `/* THREE */` would issue no diagnostics. This lead to
> the formulation of the following guidance:
>
> - `offset` must appear before `limit`.
> - `limit` and/or `offset` must appear before any of `prefix`,
> `suffix`, or `if_empty`.
[...]
> 1. Does anyone think a diagnostic on the order will help prevent
> confusion with users, even if the semantics never change between
> invocations regardless of parameter order?
I think that enforcing an order via errors or warnings will be more
confusing than the existing proposal. More to the point, the warnings
are a bad idea. Errors or no errors would be better. And I would only
introduce an error and a defined proper sequence if you want to address
the possibility of future extensions or embedded-prefixed-parameters
making ordering semantically meaningful.
>From a standards wording perspective, it might be useful to mention that
limit(0) enforces that the resource is considered empty in
[cpp.embed.param.limit], even if only as a note. Although this is
stated clearly due to the combination of [cpp.embed.gen]¶5 and
[cpp.embed.param.limit]¶3, as well as being pointed out in an example in
[cpp.embed.param.if.embed]¶2, I think that calling this out in
[cpp.embed.param.limit] might help alleviate confusion.
--
Michael Welsh Duggan
(m...@md5i.com)
