From: "Pali Rohár" <pali.rohar@gmail.com>
To: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] * grub-core/fs/udf.c: Add support for UUID
Date: Thu, 11 May 2017 12:59:20 +0200 [thread overview]
Message-ID: <20170511105920.GG9912@pali> (raw)
In-Reply-To: <201705081624.24841@pali>
On Monday 08 May 2017 16:24:24 Pali Rohár wrote:
> On Monday 08 May 2017 15:13:28 Vladimir 'phcoder' Serbinenko wrote:
> > On Mon, Apr 10, 2017, 23:17 Pali Rohár <pali.rohar@gmail.com> wrote:
> > > char *outbuf, int normalize_utf8)
> >
> > Normalize isn't the right word. And it's not utf-8 but latin1 (called
> > compressed utf-16 by udf docs).
>
> Without this patch part read_string() expects that input string is
> either utf-8 or utf-16 in that compressed osta form. If input string is
> marked with leading 0x8 but contains invalid UTF-8 sequence (like chars
> 80-FF) then it is treated as Latin1 and converted to UTF-8 in output. So
> input "\x80" is returned as "\xC2\x80".
>
> What I need is to do not do this Latin1 --> UTF-8 conversion if input is
> marked with leading 0x8 and stay it in binary/raw/octets form. This is
> due to older versions of mkudffs which put into volset string not
> conforming to osta spec. libblkid do not do that "\x80" --> "\xC2\x80"
> conversion too so it is better to have same algorithm for providing UUID
> on running system (blkid on Linux) and in bootloader (Grub2).
>
> > Are you sure you handle utf-16 case correctly? What is the expected
> > behavior in those cases? Ideally you may want to just parse raw
> > string in caller
>
> If volsetid is stored according to osta spec, then it is handed
> correctly (both UTF-8 and UTF-16).
>
> > > + binpos = 16;
> > > + for (i = 0; i < len; ++i)
> > > + {
> > > + if (!grub_isalnum (buf[i]))
> >
> > That looks real weird. What if first byte of UUID is 'a'? What if
> > alnum part contains non-English chars.
Hm... check rather should be that buf[i] contains hexadecimal digit, not
arbitrary letter. But in most cases it is hexadecimal digit...
> > I have to admit I don't get what expected behaviour is. Can you
> > elaborate on this and enable UUID test in udf_test to check that
> > UUID matches blkid?
>
> According to osta spec, first 16 characters of volsetid are unique and
> remaining anything. First 8 characters are hexadecimal representation of
> 32bit timestamp and remaining 8 implementation free (but still are
> unique). Therefore those first 16 characters we use for generating UUID.
> Again some generators of UDF disks do not put there hexadecimal number,
> but some garbage (sometimes not valid UTF-8...) so this code generates
> alphanumeric UUID from input with fact that in most cases is input
> hexadecimal (so used as is).
>
> If you have other idea how to deal with this, let me know...
>
--
Pali Rohár
pali.rohar@gmail.com
next prev parent reply other threads:[~2017-05-11 10:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-10 18:35 [PATCH] * grub-core/fs/udf.c: Add support for UUID Pali Rohár
2017-04-19 17:48 ` Pali Rohár
2017-04-19 18:11 ` Andrei Borzenkov
2017-05-08 12:55 ` Pali Rohár
2017-05-08 13:13 ` Vladimir 'phcoder' Serbinenko
2017-05-08 14:24 ` Pali Rohár
2017-05-11 10:59 ` Pali Rohár [this message]
2017-05-12 14:39 ` Pali Rohár
2017-06-22 12:42 ` [PATCH v2] " Pali Rohár
2017-08-07 15:50 ` Vladimir 'phcoder' Serbinenko
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=20170511105920.GG9912@pali \
--to=pali.rohar@gmail.com \
--cc=grub-devel@gnu.org \
--cc=phcoder@gmail.com \
/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.