descriprion updated

Sorry, you're right.

code returns 'E' for that input

But it's valid. Can you explain why it's invalid, providing more proof than 'it seems so' ?

Fixed!
(whew)
Indeed it has been straightforward...
Just needed to generate the message length before checking and shortening the key...
Won't believe but also did run more than five million test cases on my platform... The report counts 2 000 0036 lines and takes the place on disk 897M.
Here is just its little part:

***** Random Test *****
[GE_ALONE] keytab {111111117}, n: 1, c: 8, k: 9, nchar: 15
*Actual*: 111111117, Expected: 111111117
  Message: "fxatdushvmxsrsp"
  Code: [ 7 25 2 21 5 22 20 9 29 14 25 20 19 20 17 ]
[GE_DEF] keytab {439}, n: 0, c: 0, k: 3, nchar: 21
*Actual*: 439, Expected: 439
  Message: "mtkliymerprlyvmjjzmgn"
  Code: [ 17 23 20 16 12 34 17 8 27 20 21 21 29 25 22 14 13 35 17 10 23 ]
[GE_MIRROR] keytab {76761}, n: 2, c: 2, k: 5, nchar: 29
*Actual*: 76761, Expected: 76761
  Message: "suisztsibjscepxqlouwduydelgic"
  Code: [ 26 27 16 25 27 27 25 16 8 11 26 9 12 22 25 24 18 22 27 24 11 27 32 10 6 19 13 16 9 ]
[GE_DEF] keytab {64961}, n: 0, c: 0, k: 5, nchar: 13
*Actual*: 64961, Expected: 64961
  Message: "edvtskvfhnumm"
  Code: [ 11 8 31 26 20 17 26 15 14 15 27 17 22 ]
[GE_MIRROR] keytab {3232321}, n: 2, c: 3, k: 7, nchar: 17
*Actual*: 3232321, Expected: 3232321
  Message: "igxivowqtvidjeial"
  Code: [ 12 9 27 11 25 17 24 20 22 25 11 7 12 6 12 3 15 ]

...

[GE_RAND] keytab {642319018}, n: 0, c: 0, k: 9, nchar: 13
*Actual*: 642319018, Expected: 642319018
  Message: "aeaxysrzdzdxw"
  Code: [ 7 9 3 27 26 28 18 27 12 32 8 26 26 ]
[GE_MIRROR] keytab {7979795}, n: 2, c: 3, k: 7, nchar: 13
*Actual*: 7979795, Expected: 7979795
  Message: "qkiaiwmqlvpdn"
  Code: [ 24 20 16 10 16 32 18 24 21 29 25 11 23 ]
[GE_MIRROR] keytab {5353532}, n: 2, c: 3, k: 7, nchar: 28
*Actual*: 5353532, Expected: 5353532
  Message: "gknwnafllovozgadfznsjzmrzdtm"
  Code: [ 12 14 19 26 19 4 8 17 15 20 25 20 29 9 6 7 11 29 19 22 12 31 16 23 29 9 23 15 ]
Total Tests: 5000000
    Passed: 5000000, Failed: 0, Skipped: 0

Will be surprised but it takes only fifteen seconds to run the whole test!
:o
So did run it several times...
(chuckle)

(*)

To resolve the issue @csoviii did report without forking...
Please, Could you change the line 157: nchar = ge_uint(k, NCHAR); to nchar = ge_uint(k, NCHAR-2);?
This is the consequence that i did miss two extra characters while generating mirror keys which decided to add as usual at the last moment... (facepalm)

But the problem with Mirror keys remains in the Random Test cases...
So it also needs to be refactored...

JS does not seem to be buggy! In this particular case it just has another concept of keys especially as i did say when the length is same both for the key and the message...

Fixing...

It seems you spent a lot of time on it :) Thanks!

The original idea was :

   s  c  o  u  t
  19  3 15 21 20
 + 1  9  3  9  1
 ---------------
  20 12 18 30 21

And it should return 1939 key - the shortest possible key.

It was a long time ago and my JS skills were pathetic at that time too ;) If you think it's bugged in JS, I'll check it. Let me know.

Report:
Did some research and found the thing more serious...
It seems there are some concept misunderstandings...
Try to do my best to explain!
But let's consider:

• the keys like 1212 or 123123 and so on to be CYCLIC or PERIODIC keys
• the keys like 121 or 1231231 or 12312312 and so on to be MIRROR keys
• the keys like 112 or 1111113 and so on to be ALONE keys

So mainly it regards the keys where the first digit matches the last one and the length is the same for both the key and the message and also the keys having its digits repeated partially which i did call MIRROR keys!

Let's consider some examples:

   a  b  c  d  e  f  g
   1  2  3  4  5  6  7
 + 1  2  3  4  5  6  1
 ----------------------
   2  4  6  8 10 12  8

Here the translations return 123456 but should return the key 1234561 because the key is NOT CYCLIC but MIRROR and if continued to be used should generate the code:

   a  b  c  d  e  f  g    h  i  j  k  l  m  n 
   1  2  3  4  5  6  7    8  9 10 11 12 13 14
 + 1  2  3  4  5  6  1    1  2  3  4  5  6  1
 ----------------------  --------------------
   2  4  6  8 10 12  8    9 11 13 15 17 19 15

And NOT this one which is wrong if considered to be CYCLIC:

   a  b  c  d  e  f  g    h  i  j  k  l  m  n 
   1  2  3  4  5  6  7    8  9 10 11 12 13 14
 + 1  2  3  4  5  6  1    2  3  4  5  6  1  2
 ----------------------  --------------------
   2  4  6  8 10 12  8   10 12 14 16 18 14 16

So the opinion here is that the key should have been shortcut ONLY if it is COMPLETELY CYCLIC.
Otherwise, if partially repeated MIRROR one should return as-is!

Mainly the problem surfaced because the C generator tries to test for the different types of keys but the C solution implementation and the Generic Test set cases relied on the JS Translation and here the implementation is wrong but valid because of not being tested comepletely...

So what's the decision?

Reviewing...
Thanks!

Thanks! It's @uniapi 's translation. I hope he'll check it.

What language?