From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1d8log-0001nQ-0w for mharc-grub-devel@gnu.org; Thu, 11 May 2017 06:59:30 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d8lod-0001mh-7d for grub-devel@gnu.org; Thu, 11 May 2017 06:59:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d8loZ-000200-AB for grub-devel@gnu.org; Thu, 11 May 2017 06:59:27 -0400 Received: from mail-wm0-x244.google.com ([2a00:1450:400c:c09::244]:35790) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d8loZ-0001z2-4e for grub-devel@gnu.org; Thu, 11 May 2017 06:59:23 -0400 Received: by mail-wm0-x244.google.com with SMTP id v4so6111869wmb.2 for ; Thu, 11 May 2017 03:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=zQIRxdIhp7kieo6uL6ioDxMnM6d0jdll0Rc1+aA+cV8=; b=L5I400LQyAARUx8kA2xAisyKcdYB8k4ost++ck0g9NqJ0sMDRLIMtXotL46cZvjzah gAYpLGr8E8KXwNHmVIFev52gSnEj5LaRMGWUUHvK2uRwDe5t5s/ytDekmPy+fQ2u+Rz+ 7m6+Rn+lCYbndEmY9VgBAT3H1fljgiK947sV6cBJCHpkIsrNSY0RCByem/7sX6fPGOJb kKJcwaBMcFiSiMHbS8j5jPIU31J4Fl7fVlRNVAI/VDy1a8DgDPfC8Lj+XF1f0n7n+wkw nGo67Jt8ZplU9BZyo/9G6rotSdJcwt3QX/gqzXfpisnL22a8GNMtlsC2koLTTGPmMaSF KNZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=zQIRxdIhp7kieo6uL6ioDxMnM6d0jdll0Rc1+aA+cV8=; b=JBtHIpSSC7c0PNB4Xfp6eswHh9t3LaN/jqbmecT8tRq3jSY0T4QLPFan0jPmjuEqCn n6nFnNgnejOjZhAGhB8U2pWzXlCmACuE1LWpCpV0jn2/L2rLF8cg51JuQ1NSu/uAzoB3 TnFBSTOlB5+e2cC84qRLabnxk0IwBNBR2V1zZVXVUnedQT3y3R9IyNM1UneW5rL6jJsy x79PybAFbBvm+ThAbixCluLV0sN3zt7m9G+1xROf+42pFOEmqVyTnsnELwhejofJLufz uDnowTKhkpTnTsdvCDDiO/MgEorE7NtYukZf4kq1zGS0Qz1/r31AS4c6br1lwf060Wfb 2FlA== X-Gm-Message-State: AODbwcDCV1979DNCMVd18AD2/C2ZYLu+rqENJt3FS6V73sc8/CR5gyRh 3hWc5V44A1742Q== X-Received: by 10.28.168.3 with SMTP id r3mr4193945wme.33.1494500361661; Thu, 11 May 2017 03:59:21 -0700 (PDT) Received: from pali (atrey.karlin.mff.cuni.cz. [195.113.26.193]) by smtp.gmail.com with ESMTPSA id q140sm263306wmb.14.2017.05.11.03.59.20 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 11 May 2017 03:59:20 -0700 (PDT) Date: Thu, 11 May 2017 12:59:20 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Vladimir 'phcoder' Serbinenko Cc: The development of GNU GRUB Subject: Re: [PATCH] * grub-core/fs/udf.c: Add support for UUID Message-ID: <20170511105920.GG9912@pali> Reply-To: Pali =?utf-8?B?Um9ow6Fy?= References: <1491849330-10140-1-git-send-email-pali.rohar@gmail.com> <201705081624.24841@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201705081624.24841@pali> User-Agent: Mutt/1.5.23.1 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::244 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 10:59:29 -0000 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 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