From owner-freebsd-sparc64@freebsd.org  Thu Mar 31 07:23:13 2016
Return-Path: <owner-freebsd-sparc64@freebsd.org>
Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 450C8AE306F
 for <freebsd-sparc64@mailman.ysv.freebsd.org>;
 Thu, 31 Mar 2016 07:23:13 +0000 (UTC)
 (envelope-from j@uriah.heep.sax.de)
Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9])
 by mx1.freebsd.org (Postfix) with ESMTP id 0D506128F
 for <freebsd-sparc64@freebsd.org>; Thu, 31 Mar 2016 07:23:13 +0000 (UTC)
 (envelope-from j@uriah.heep.sax.de)
Received: by uriah.heep.sax.de (Postfix, from userid 107)
 id 702D43E71; Thu, 31 Mar 2016 09:23:03 +0200 (CEST)
Date: Thu, 31 Mar 2016 09:23:03 +0200
From: Joerg Wunsch <j@uriah.heep.sax.de>
To: freebsd-sparc64@freebsd.org
Cc: Shigeharu TAKENO <shige@iee.niit.ac.jp>
Subject: Re: /usr/bin/sort may be incorrect
Message-ID: <20160331072303.GP53011@uriah.heep.sax.de>
Reply-To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
References: <201603250229.u2P2TVLp003567@pc98tak.iee.niit.ac.jp>
 <201603310446.u2V4kLGM003303@pc98tak.iee.niit.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201603310446.u2V4kLGM003303@pc98tak.iee.niit.ac.jp>
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F  93 21 E0 7D F9 12 D6 4E
X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584  1070 F48C A81B 69A8 5873
User-Agent: Mutt/1.5.23 (2014-03-12)
X-BeenThere: freebsd-sparc64@freebsd.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: Porting FreeBSD to the Sparc <freebsd-sparc64.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-sparc64>, 
 <mailto:freebsd-sparc64-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-sparc64/>
List-Post: <mailto:freebsd-sparc64@freebsd.org>
List-Help: <mailto:freebsd-sparc64-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64>, 
 <mailto:freebsd-sparc64-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2016 07:23:13 -0000

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. ;-)