From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16837: Invalid memory access on \h in psql
In-reply-to: <20210126.201709.717799732421886750.horikyota.ntt@gmail.com>
References: <16837-479bcd56040c71b3@postgresql.org>
 <20210126.201709.717799732421886750.horikyota.ntt@gmail.com>
Comments: In-reply-to Kyotaro Horiguchi <horikyota.ntt@gmail.com>
	message dated "Tue, 26 Jan 2021 20:17:09 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2176556.1611677482.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jan 2021 11:11:22 -0500
Message-ID: <2176557.1611677482@sss.pgh.pa.us>
Precedence: bulk

Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Tue, 26 Jan 2021 07:00:00 +0000, PG Bug reporting form <noreply@postg=
resql.org> wrote in =

>> When executing in psql (under valgrind):
>> \h\
>> valgrind detects the following error:
>> =3D=3D00:00:00:00.000 3226182=3D=3D =

>> =3D=3D00:00:00:04.045 3226182=3D=3D Conditional jump or move depends on
>> uninitialised value(s)

> This is reproducible on master HEAD. helpSQL assumes that the first
> word is longer than two characters and the second word exists. It also
> doesn't care overruns. Addition to those issues, it miscounts the
> length of the first two words if the third word exists.

Weirdly, valgrind isn't whining about this for me.  But I agree that
that loop is unsafe.  There are other problems too I think: neither
the initialization of "output" nor the calculation of nl_count seem
to be done sanely.  This function really needs thoroughgoing review :-(

			regards, tom lane