Problem with C stub in contributions

Hello,
I’m not an expert in C, but for two contributions, I got the remark, that the C-stub is not working:


(comment by @ahornik)


(comment by @Heliferepo and the answer by @abt8601 might also be interesting)

This problem seems to occur, when you have to read one character in the first and a string in the second line. With the generated stub, you read the two lines in two variables, but the second variable is always empty. This problems disappears if you read three values and only use the first and the third.
Is this a problem with my code for the generation of the stub or with the stub itself?

Thanks

2 Likes

I’ll ask the stub experts :smiley:

1 Like

read c:string(1) gets translated to char c[2]; fgets(c, 2, stdin);
But it should be char c[3]; fgets(c, 3, stdin); as you read the actual text, the linebreak and the \0 to terminate the string.
You can verify it like this: for (int i = 0; i < 3; i++) printf("%d ", c[i]); // print 100 10 0 (with 100='d')

I remember @Niako reporting that about a year ago. It also caused some hiccups in the last contest, see stub.txt.

edit: Link to Niako’s post

3 Likes

Same problem in https://www.codingame.com/ide/puzzle/encryptiondecryption-of-enigma-machine
the rotor read fgets(rotor, 27, stdin); leaves out the \n so it’s messing out the next rotor read.
I suggest to change to fgets(rotor, 27, stdin); fgetc(stdin); this way the rotor string will not contain the \n.

As mentioned, it’s a known problem with the stub generator that will hopefully eventually be fixed by CG.
I fixed it manually by increasing the size of the expected string (string(2) — which is actually 2+1 with the current generator for C — to parse 1 char + "\n\0" in C).
I did the same with the puzzle mentioned by @The_Auditor (and already answered here).

1 Like