illumos gate

usr/src/cmd/localedef/ctype.c

Line 276:
CID 1338565 (#1 of 1): Buffer not null terminated (BUFFER_SIZE_WARNING)
2. buffer_size_warning: Calling strncpy with a maximum size argument of 32 bytes on destination array rl.encoding of size 32 bytes might leave the destination string unterminated.

The line is: (void) strncpy(rl.encoding, get_wide_encoding(), sizeof (rl.encoding));

So the third argument needs to have -1 appended. This is at present harmless since the encoding names are all short enough not to trip on this.

Line 348:
CID 1338557 (#1 of 1): Operands don't affect result (CONSTANT_EXPRESSION_RESULT)
result_independent_of_operands: ctn->ctype & 0x2000L & (ctn->ctype & (66816L /* (0x400L | 0x100L) | 0x10000L */)) is always 0 regardless of the values of its operands. This occurs as the logical operand of if.

This line is the error:

                if ((ctn->ctype & _ISPUNCT) &
                    (ctn->ctype & (_ISDIGIT|_ISALPHA|_ISXDIGIT)))
                        conflict++;

The first "&" should be &&. Its harmless in that the check should always be false anyway, but we should fix.

Line 429:

CID 1338540 (#1 of 1): Resource leak (RESOURCE_LEAK)
127. leaked_storage: Variable up going out of scope leaks the storage it points to
CID 1338541 (#1 of 1): Resource leak (RESOURCE_LEAK)
127. leaked_storage: Variable lo going out of scope leaks the storage it points to.
CID 1338566 (#1 of 1): Resource leak (RESOURCE_LEAK)
127. leaked_storage: Variable ct going out of scope leaks the storage it points to.

We should add conditional frees at the end of the function:

if (up != NULL) 
   free(up);
if (ct != NULL)
   free(ct);
if (lo != NULL)
   free(lo);

Additionally the return from the failure to write any of these needs to probably have a goto statement to the end of the function, where the free routines noted above are.

/usr/src/cmd/localedef/time.c

Line 74 (Breaks from switch)
Line 80:

CID 1338535 (#1 of 1): Resource leak (RESOURCE_LEAK)
6. leaked_storage: Variable str going out of scope leaks the storage it points to.

This one is actually a leak of the str.  We should probably just do free(str) before the break.

Thanks to Pedro Giffuni from the FreeBSD team for sending these to me.

None of these issues are terribly urgent, but this makes a nice bite-size bug for a new contributor to handle.