Re: /usr/bin/sort may be incorrect

Joerg Wunsch <[email protected]>
Newsgroups gmane.os.freebsd.devel.sparc
Message-ID <[email protected]>
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. ;-)
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.