That doesn't really translate C to Rust, it compiles it to unsafe Rust with all the weaknesses of the C code. It doesn't even use Rust arrays. You would not want to maintain what comes out. It turns

    p[j] = p[j-1];

into

    *p.offset(j as isize) = *p.offset((j - 1 as libc::c_int) as isize);

which is unmaintainable.

If you put in

    void insertion_sort(int const n, int const p[]) 

you get

    pub unsafe extern "C" fn 
        insertion_sort(n: libc::c_int,
                       mut p: *const libc::c_int) 

C has no way to say how big p is. (Biggest flaw in the design of C). That info is essential to translating this properly. The translator needs either a hint from the user, or inference from examining the calls to the function.

Now, if you could stick something like

    ASSERT(LENGTHOF(p) == n);

which would be ignored by C if ASSERT was defined to ignore it, and the Rust translator understood that, it could use a Rust array, which has a size. Now the output Rust code could use subscripts properly.

Generating constraints like that is a hard problem, but providing an interactive tool which prompts the user on where to insert them is not.