[rb-general] rb-prefix-map spec: don't be as democratic to consumers

Ximin Luo infinity0 at debian.org
Sun Mar 5 20:30:00 CET 2017


Daniel Shahaf:
> Hi,
> 
> https://github.com/infinity0/rb-prefix-map/blob/master/spec-main.rst#applying-the-decoded-structure
> currently says:
> 
>> Consumers SHOULD implement one of the following algorithms:
>>
>> 1. …
>>
>> 2. …
> 
> The two algorithms, #1 and #2, have different semantics.
> 
> I think specifications MUST NOT allow consumers leeway to choose between
> different semantics.  (Why?  Just imagine a world in which gcc
> implemented #1 and clang implemented #2; in such a world, gcc and clang
> wouldn't be interchangeable.)
> 
> So, I propose:
> 
> a. Specify precisely which semantics consumers MUST implement.  The spec
> MAY recommend a particular algorithm, but MUST NOT give consumers choice
> of semantics.
> 
> b. I have no opinion as to _which_ semantics consumers should implement;
> whether the #1 semantics, the #2 semantics, or possibly something else.
> 
> Cheers,
> 
> Daniel
> 
> P.S. Use-case: imagine a compression program that links two different
> libxz versions and allows choosing between them at runtime.  The source
> of that program might include /foo/xz-42/main.c and /foo/xz-43/main.c
> and its build system might then define BUILD_PATH_PREFIX_MAP="/foo/xz=xz".
> If the build system then started using a different C compiler, the
> program would no longer be reproducible.
> 
> P.P.S. Sorry for not catching this earlier, I was a bit busy for the
> past few weeks.

Hey, no worries and thanks for the input.

I did think about this, but decided in the end against it because I didn't think it was necessary, and might hinder adoption in case a consumer really thought the specific algorithm was not so good - and TBH I personally think (2) is better than (1) which GCC implements. (2) was originally suggested in a Rust debuginfo thread that I had been participating in.

I think it's not necessary, because in general we don't expect two tools to generate the same output, nor even one tool at different versions to do that. So GCC and Clang implementing different algorithms don't matter, as long as they both read the variable in the same way, and their output is reproducible given the same reading of the same variable and the same build paths being used. Similarly with two different versions of libxz.

Does that make sense? Happy to talk about it more though, if you don't think my reasoning just now was good.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git


More information about the rb-general mailing list