/usr/bin/sort may be incorrect

Joerg Wunsch j at uriah.heep.sax.de
Thu Mar 31 07:23:13 UTC 2016


As Shigeharu TAKENO wrote:

> I found the workaround for the problem:
> 
> ----- From here -----
> --- /usr/src/usr.bin/sort/coll.h.ORG	2016-03-31 13:23:24.226753000 +0900
> +++ /usr/src/usr.bin/sort/coll.h	2016-03-31 13:24:23.469436000 +0900
> @@ -90,7 +90,11 @@
>  struct key_value
>  {
>  	struct bwstring		*k; /* key string */
> +#if 0
>  	struct key_hint		 hint[0]; /* key sort hint */
> +#else
> +	struct key_hint		 hint[1]; /* key sort hint */
> +#endif
>  };

Well, depending on how the storage for the elements is reserved, this
might allocate too much memory (one struct key_hint too much).  Not a
big problem though, I guess.

Declaring the trailing array member of a struct as 0-sized used to be
a private GCC extension.  C99 standardized it in a somewhat different
way:

struct key_value
{
   struct bwstring *k;
   struct key_hint hint[];
};

If that works for you, too, I think it would be the preferrable way to
write it.

> The k field of key_value may be overwritten by the hint field
> in numcoll_impl(), gnumcoll() and monthcoll() (coll.c), and the
> pointer value of k may change to incorrect value.

Are you saying that something like

struct key_value *kw;

...

   kw->hint[-1] = something;

happens?  That would certainly be a bug in the code then that ought to
be fixed, rather than worked around.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)


More information about the freebsd-sparc64 mailing list