{"thread":{"id":"50467","subject":"[PATCH] t0028: fix wrong octal values for BOM in setup","startedAt":"2019-02-11T21:38:24Z","lastAt":"2019-02-11T22:42:54Z","messageCount":2,"participants":["Kevin Daudt","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"369040","messageId":"20190211213818.4941-1-me@ikke.info","threadId":"50467","inReplyTo":null,"subject":"[PATCH] t0028: fix wrong octal values for BOM in setup","fromName":"Kevin Daudt","fromEmail":"me@ikke.info","sentAt":"2019-02-11T21:38:18Z","receivedAt":"2019-02-11T21:38:24Z","isPatch":true,"sender":{"key":"me@ikke.info","avatar":"https://avatars.githubusercontent.com/u/135698?v=4"},"body":"The setup code uses octal values with printf to generate a BOM for\nUTF-16/32 BE/LE. It specifically uses '\\777' to emit a 0xff byte. This\nrelies on the fact that most shells truncate the value above 0o377.\n\nAsh however interprets '\\777' as '\\77' + a literal '7', resulting in an\ninvalid BOM.\n\nFix this by using the proper value of 0xff: '\\377'.\n\nSigned-off-by: Kevin Daudt <me@ikke.info>\n---\nI do wonder why this code is using octal values in the first place,\nrather than using hex values.\n\n t/t0028-working-tree-encoding.sh | 8 ++++----\n 1 file changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/t/t0028-working-tree-encoding.sh b/t/t0028-working-tree-encoding.sh\nindex 8936ba6757..c6b68c22ca 100755\n--- a/t/t0028-working-tree-encoding.sh\n+++ b/t/t0028-working-tree-encoding.sh\n@@ -49,12 +49,12 @@ test_expect_success 'setup test files' '\n \t# BOM tests\n \tprintf \"\\0a\\0b\\0c\"                         >nobom.utf16be.raw &&\n \tprintf \"a\\0b\\0c\\0\"                         >nobom.utf16le.raw &&\n-\tprintf \"\\376\\777\\0a\\0b\\0c\"                 >bebom.utf16be.raw &&\n-\tprintf \"\\777\\376a\\0b\\0c\\0\"                 >lebom.utf16le.raw &&\n+\tprintf \"\\376\\377\\0a\\0b\\0c\"                 >bebom.utf16be.raw &&\n+\tprintf \"\\377\\376a\\0b\\0c\\0\"                 >lebom.utf16le.raw &&\n \tprintf \"\\0\\0\\0a\\0\\0\\0b\\0\\0\\0c\"             >nobom.utf32be.raw &&\n \tprintf \"a\\0\\0\\0b\\0\\0\\0c\\0\\0\\0\"             >nobom.utf32le.raw &&\n-\tprintf \"\\0\\0\\376\\777\\0\\0\\0a\\0\\0\\0b\\0\\0\\0c\" >bebom.utf32be.raw &&\n-\tprintf \"\\777\\376\\0\\0a\\0\\0\\0b\\0\\0\\0c\\0\\0\\0\" >lebom.utf32le.raw &&\n+\tprintf \"\\0\\0\\376\\377\\0\\0\\0a\\0\\0\\0b\\0\\0\\0c\" >bebom.utf32be.raw &&\n+\tprintf \"\\377\\376\\0\\0a\\0\\0\\0b\\0\\0\\0c\\0\\0\\0\" >lebom.utf32le.raw &&\n \n \t# Add only UTF-16 file, we will add the UTF-32 file later\n \tcp test.utf16.raw test.utf16 &&\n-- \n2.19.1\n\n"},{"id":"369049","messageId":"xmqq36ougd5i.fsf@gitster-ct.c.googlers.com","threadId":"50467","inReplyTo":"20190211213818.4941-1-me@ikke.info","subject":"Re: [PATCH] t0028: fix wrong octal values for BOM in setup","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-02-11T22:42:49Z","receivedAt":"2019-02-11T22:42:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Daudt <me@ikke.info> writes:\n\n> The setup code uses octal values with printf to generate a BOM for\n> UTF-16/32 BE/LE. It specifically uses '\\777' to emit a 0xff byte. This\n> relies on the fact that most shells truncate the value above 0o377.\n>\n> Ash however interprets '\\777' as '\\77' + a literal '7', resulting in an\n> invalid BOM.\n>\n> Fix this by using the proper value of 0xff: '\\377'.\n>\n> Signed-off-by: Kevin Daudt <me@ikke.info>\n> ---\n> I do wonder why this code is using octal values in the first place,\n> rather than using hex values.\n\nMost likely for portability to non GNU and less widely used systems.\n\nThanks for spotting these \\777s.\n\nWill apply.\n"}]}