From: Dave Gordon <david.s.gordon@intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8
Date: Fri, 22 Apr 2016 12:27:29 +0100 [thread overview]
Message-ID: <571A0AA1.5070403@intel.com> (raw)
In-Reply-To: <20160421151343.GA3763@redhat.com>
On 21/04/16 16:13, Peter Jones wrote:
> On Thu, Apr 21, 2016 at 01:18:27PM +0100, Matt Fleming wrote:
>> ( Good Lord, I hate doing string manipulation in C )
>
> (yep)
>
>>
>> On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote:
>>>
>>> So, "len" does not include the room for the terminating NUL-byte here.
>>> When "len" is passed to ucs2_as_utf8(), with the proposed patch applied,
>>> a NUL byte will be produced in "name", but it will be at the price of a
>>> genuine character from the input variable name.
>>
>> Right, and this is a problem because we're trying to keep the names
>> consistent between efivarfs and the EFI variable data. Force
>> NUL-terminating the string is wrong, because if you have no room for
>> the NUL the caller should check for that. Sadly none do.
>>
>> On the flip-side, passing around non-NUL terminated strings is just
>> begging for these kinds of issues to come up.
>>
>> The fact is that the callers of ucs2_as_utf8() are passing it the
>> wrong 'len' argument. We want a NUL-terminated utf8 string and we're
>> passing a NUL-terminated ucs2 string. We should tell ucs2_as_utf8() it
>> has enough room to copy the NUL.
>>
>> Wouldn't this work (minus the return value checking)?
>
> I agree with your analysis, and your patch looks plausible.
This isn't really any different from the plain old ASCII case, where a
function might call strlen(), allocate a buffer, and strncpy() the
non-NUL bytes into it.
It would of course then be wrong to pass that to any of the standard
string functions that operate on NUL-terminated strings.
OTOH if the code knows that the next thing will be an append @buf[len],
then the temporary lack of a NUL isn't an issue.
Personally I'd be inclined to keep my strings NUL-terminated at all
times, just as a guard against forgetting that I should only use
functions that take an explicit length.
The pattern:
l1 = strlen(s1);
l2 = strlen(s2);
buf = malloc(l1+l2+1);
strcpy(buf, s1);
strcpy(buf+l1, s2);
is quite common, quite safe, and not likely to confuse anyone. The extra
overwrites of the temporary NULs are a small price for those benefits.
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-04-22 11:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 8:37 [PATCH] lib: Always NUL terminate ucs2_as_utf8 Chris Wilson
2016-04-20 8:37 ` Chris Wilson
[not found] ` <1461141427-16361-1-git-send-email-chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
2016-04-20 9:36 ` Laszlo Ersek
2016-04-20 9:36 ` Laszlo Ersek
2016-04-20 9:41 ` Chris Wilson
2016-04-20 9:41 ` Chris Wilson
2016-04-20 12:45 ` Laszlo Ersek
2016-04-20 12:45 ` Laszlo Ersek
2016-04-20 13:25 ` Laszlo Ersek
2016-04-20 13:25 ` Laszlo Ersek
[not found] ` <5717834C.6070802-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-04-21 12:18 ` Matt Fleming
2016-04-21 12:18 ` Matt Fleming
2016-04-21 15:13 ` Peter Jones
2016-04-21 15:13 ` Peter Jones
2016-04-22 11:27 ` Dave Gordon [this message]
2016-04-21 16:21 ` Laszlo Ersek
2016-04-21 16:21 ` Laszlo Ersek
2016-04-22 18:52 ` Matt Fleming
2016-04-22 18:52 ` Matt Fleming
[not found] ` <20160422185210.GG2829-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-04-25 10:17 ` Laszlo Ersek
2016-04-25 10:17 ` Laszlo Ersek
2016-04-20 14:03 ` [Intel-gfx] " Jani Nikula
2016-04-20 14:03 ` Jani Nikula
2016-04-20 10:57 ` ✓ Fi.CI.BAT: success for " Patchwork
2016-04-22 9:58 ` ✗ Fi.CI.BAT: warning " Patchwork
2016-04-22 16:27 ` ✓ Fi.CI.BAT: success " Patchwork
2016-04-24 13:36 ` Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=571A0AA1.5070403@intel.com \
--to=david.s.gordon@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.