A (very few) about GIF compression

The code size (the number of bits to output one code) has to be incremented as soon as the code in the table exceeds the biggest representable code (one must not wait until the code to be actually output exceeds this value). This is obvious, since the decoder can't know if the next code to read has to be read on n or n+1 bits.
Loseless doesn't mean identical files: the same images converted to GIF by two different encoders may result in two totally different files, although they'll be of the same length. The reason is that the encoder may choose the values for the color indexes the way it likes, provided the color table is accordingly adjusted.
Jasmin Blanchette says rightly about the file differences:
They won't necessarily be of the same length: as the GIF89a specification point out, encoders may or may not send clear codes at any time to reset the string table, which defininitely affects file length. Generally speaking, different encoders have different behaviors with respect to this.

The important point is that when writing an encoder, you may be tempted to compare the output of your program with a known encoder. Having different output doesn't mean that either of the encoders is wrong.