bug#22366: [EXT] Bug#22366 Status? Chicken Scheme release tarballs ship non-source C code

[zimoun]

Dear David,

On Thu, 14 May 2020 at 21:04, Thompson, David <address@hidden> wrote:

> > Why is it an issue for bootstrappability?
>
> Because software is not bootstrappable if it requires taking for
> granted files that are not source code.  In this case, it is these C
> files.  These files are not source code because they are machine
> generated.  In order to generate these files, you need a Chicken
> Scheme compiler.  Therefore, you cannot build Chicken Scheme from
> source code without already having Chicken Scheme, which makes it
> non-bootstrappable.  I have not kept track of this issue but my
> understanding was that the Chicken developers do not care (which is
> unfortunately a very common reaction from developers of self-hosted
> compilers) but it is nevertheless a bootstrapping issue.

I am not following your reasoning.  The point is not how the C files
are generated but if they are auditable. -- which in most of the cases
means human-readable.

Considering these generated C files, even if I am not a C expert, they
seems un-auditable.

--8<---------------cut here---------------start------------->8---
C_noret_decl(f24858)
static void C_ccall f24858(C_word c,C_word *av) C_noret;
C_noret_decl(f_10015)
static void C_ccall f_10015(C_word c,C_word *av) C_noret;
C_noret_decl(f_10019)

[...]

/* k10021 in k10017 in a10014 in k9990 in k9987 in k9984 in k8730 in
k8463 in k8451 in k8448 in k8445 in k8441 in k8438 in k8432 in k8393
in walk in chicken.compiler.core#canonicalize-expression in k6295 in
k6292 in k6289 in k6286 in k6283 in ... */
static void C_ccall f_10023(C_word c,C_word *av){
C_word tmp;
C_word t0=av[0];
C_word t1=av[1];
C_word t2;
C_word t3;
C_word t4;
C_word *a;
if(C_unlikely(!C_demand(C_calculate_demand(4,c,4)))){
C_save_and_reclaim((void *)f_10023,c,av);}
a=C_alloc(4);
t2=C_mutate(((C_word *)((C_word*)t0)[2])+1,t1);
t3=(*a=C_CLOSURE_TYPE|3,a[1]=(C_word)f_10026,a[2]=((C_word*)t0)[3],a[3]=((C_word*)t0)[4],tmp=(C_word)a,a+=4,tmp);
/* core.scm:890: ##sys#current-environment1643 */
t4=((C_word*)t0)[5];{
C_word *av2;
if(c >= 5) {
  av2=av;
} else {
  av2=C_alloc(5);
}
av2[0]=t4;
av2[1]=t3;
av2[2]=((C_word*)t0)[6];
av2[3]=C_SCHEME_FALSE;
av2[4]=C_SCHEME_TRUE;
((C_proc)(void*)(*((C_word*)t4+1)))(5,av2);}}
--8<---------------cut here---------------end--------------->8---


> I don't think this can be closed because it is still an issue.

I have failed to generated these C files using another scheme
interpreter.  Yeah, it is more than a hack between the coffee and the
shower. :-)


Thank you for the clarifications and it is still an issue. :-)

All the best,
simon