> -----Original Message----- > From: Rob Herring [mailto:robherring2@xxxxxxxxx] > Sent: Wednesday, April 08, 2015 10:26 PM > To: Liu Shengzhou-B36685 > Cc: devicetree@xxxxxxxxxxxxxxx; Grant Likely > Subject: Re: [PATCH] of: fix of_property_read_string > > On Wed, Apr 8, 2015 at 1:29 AM, Shengzhou.Liu@xxxxxxxxxxxxx > <Shengzhou.Liu@xxxxxxxxxxxxx> wrote: > >> On Tue, Apr 7, 2015 at 5:11 AM, Shengzhou Liu > >> <Shengzhou.Liu@xxxxxxxxxxxxx> wrote: > >> > In of_property_read_string function, strnlen(prop->value, > >> > prop->length) is always less or equal to prop->length, and we > >> > prop->should > >> allow the '==' > >> > condition, so let's remove the original unreasonable condition. > >> > >> I believe we don't want to allow equal because prop->length should > >> include the \0 termination while strnlen will not. > >> > >> Rob > > > > Yes, I thought so, ideally prop->length should be assigned with > > strlen(value)+1, but unfortunately in u-boot and kernel there are too > > many callers that have prop->length assigned with strlen(value) instead of > > strlen(value)+1, in practice, we can allow equal. > > > > No one should touch prop->length and it comes from the DTB directly. > It doesn't come from strlen. > e.g. u-boot changes prop->length dynamically by fdt_setprop(). we can fix it by using strlen()+1 instead of strlen() in u-boot. well, let's drop the patch. ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
