/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