[PATCH] crypto: convert "crypto" subdirectory to UTF-8

[PATCH] crypto: convert "crypto" subdirectory to UTF-8

[John Anthony Kazos Jr.]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1701 bytes --]

From: John Anthony Kazos Jr. <jakj@j-a-k-j.com>

Convert the subdirectory "crypto" to UTF-8. The files changed are 
<crypto/fcrypt.c> and <crypto/api.c>.

Signed-off-by: John Anthony Kazos Jr. <jakj@j-a-k-j.com>

---

I can't get my mail client to send in ISO-8859-1 instead of UTF-8, so the 
actual patch is attached in octet-stream format. The below patch is just 
for reference and will almost certainly NOT work.

Also, since the patch includes both encodings, whichever encoding you 
select while viewing it will display one correct and one garbled line. 
However, the bytecodes -are- correct.

diff -uprN linux-2.6.21-rc7.orig/crypto/api.c linux-2.6.21-rc7.mod/crypto/api.c
--- linux-2.6.21-rc7.orig/crypto/api.c	2007-04-17 11:41:50.000000000 -0400
+++ linux-2.6.21-rc7.mod/crypto/api.c	2007-04-17 13:21:52.000000000 -0400
@@ -6,7 +6,7 @@
  * Copyright (c) 2005 Herbert Xu <herbert@gondor.apana.org.au>
  *
  * Portions derived from Cryptoapi, by Alexander Kjeldaas <astor@fast.no>
- * and Nettle, by Niels Möller.
+ * and Nettle, by Niels Möller.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the Free
diff -uprN linux-2.6.21-rc7.orig/crypto/fcrypt.c linux-2.6.21-rc7.mod/crypto/fcrypt.c
--- linux-2.6.21-rc7.orig/crypto/fcrypt.c	2007-04-17 11:41:50.000000000 -0400
+++ linux-2.6.21-rc7.mod/crypto/fcrypt.c	2007-04-17 13:21:52.000000000 -0400
@@ -10,7 +10,7 @@
  *
  * Based on code:
  *
- * Copyright (c) 1995 - 2000 Kungliga Tekniska Högskolan
+ * Copyright (c) 1995 - 2000 Kungliga Tekniska Högskolan
  * (Royal Institute of Technology, Stockholm, Sweden).
  * All rights reserved.
  *

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 1102 bytes --]

diff -uprN linux-2.6.21-rc7.orig/crypto/api.c linux-2.6.21-rc7.mod/crypto/api.c
--- linux-2.6.21-rc7.orig/crypto/api.c	2007-04-17 11:41:50.000000000 -0400
+++ linux-2.6.21-rc7.mod/crypto/api.c	2007-04-17 13:21:52.000000000 -0400
@@ -6,7 +6,7 @@
  * Copyright (c) 2005 Herbert Xu <herbert@gondor.apana.org.au>
  *
  * Portions derived from Cryptoapi, by Alexander Kjeldaas <astor@fast.no>
- * and Nettle, by Niels Möller.
+ * and Nettle, by Niels Möller.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the Free
diff -uprN linux-2.6.21-rc7.orig/crypto/fcrypt.c linux-2.6.21-rc7.mod/crypto/fcrypt.c
--- linux-2.6.21-rc7.orig/crypto/fcrypt.c	2007-04-17 11:41:50.000000000 -0400
+++ linux-2.6.21-rc7.mod/crypto/fcrypt.c	2007-04-17 13:21:52.000000000 -0400
@@ -10,7 +10,7 @@
  *
  * Based on code:
  *
- * Copyright (c) 1995 - 2000 Kungliga Tekniska Högskolan
+ * Copyright (c) 1995 - 2000 Kungliga Tekniska Högskolan
  * (Royal Institute of Technology, Stockholm, Sweden).
  * All rights reserved.
  *

Re: [PATCH] crypto: convert "crypto" subdirectory to UTF-8

[Stefan Richter]

John Anthony Kazos Jr. wrote:
> Convert the subdirectory "crypto" to UTF-8. The files changed are 
> <crypto/fcrypt.c> and <crypto/api.c>.

Aren't we using ASCII for C sources?
-- 
Stefan Richter
-=====-=-=== -=-- =--=-
http://arcgraph.de/sr/

Re: [PATCH] crypto: convert "crypto" subdirectory to UTF-8

[Alan Cox]

On Wed, 18 Apr 2007 11:33:29 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> John Anthony Kazos Jr. wrote:
> > Convert the subdirectory "crypto" to UTF-8. The files changed are 
> > <crypto/fcrypt.c> and <crypto/api.c>.
> 
> Aren't we using ASCII for C sources?

We haven't done that for many years - it makes it hard to spell some
authors names properly for one.

Re: [PATCH] crypto: convert "crypto" subdirectory to UTF-8

[Herbert Xu]

On Tue, Apr 17, 2007 at 01:25:49PM -0400, John Anthony Kazos Jr. wrote:
> From: John Anthony Kazos Jr. <jakj@j-a-k-j.com>
> 
> Convert the subdirectory "crypto" to UTF-8. The files changed are 
> <crypto/fcrypt.c> and <crypto/api.c>.
> 
> Signed-off-by: John Anthony Kazos Jr. <jakj@j-a-k-j.com>

Thanks.  Could you fix up include/linux/crypto.h as well?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: convert "crypto" subdirectory to UTF-8

[John Anthony Kazos Jr.]

> > Convert the subdirectory "crypto" to UTF-8. The files changed are 
> > <crypto/fcrypt.c> and <crypto/api.c>.
> > 
> > Signed-off-by: John Anthony Kazos Jr. <jakj@j-a-k-j.com>
> 
> Thanks.  Could you fix up include/linux/crypto.h as well?

Sure, will do. Since I've gotten almost no feedback about these patches 
whatsoever, I figured either I was doing it wrong or nobody cared. I guess 
I'll finish them all up and resubmit them and hope they stick. Gimme a 
few days: There's a huge number of files throughout the tree to change, 
and some of them (like the .map files) require non-trivial alterations.

(Were you able to successfully apply the patch attached in octet-stream 
encoding?)

Re: [PATCH] crypto: convert "crypto" subdirectory to UTF-8

[Herbert Xu]

John Anthony Kazos Jr. <jakj@j-a-k-j.com> wrote:
>
> (Were you able to successfully apply the patch attached in octet-stream 
> encoding?)

Yes it worked fine.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] crypto: convert crypto.h to UTF-8

[John Anthony Kazos Jr.]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1218 bytes --]

From: John Anthony Kazos Jr. <jakj@j-a-k-j.com>

Convert the encoding of <include/linux/crypto.h> from ISO-8859-1 to UTF-8.

Signed-off-by: John Anthony Kazos Jr. <jakj@j-a-k-j.com>

---

Did this file individually, per request. Will re-do the whole tree later 
as I'm still working on my handy-dandy testing and patching tools and 
don't have a lot of time outside of work until the summer gets underway.

The patch works in ISO-8859-1 encoding. If I am unsuccessful in getting 
this mail to send as that, or if your viewer reinterprets it from that, 
you'll need to use the file attached as MIME type octet-stream. Thanks for 
your time and interest.

--- linux-2.6.21-rc7-git4.orig/include/linux/crypto.h	2007-04-20 20:22:13.000000000 -0400
+++ linux-2.6.21-rc7-git4.mod/include/linux/crypto.h	2007-05-03 07:09:47.000000000 -0400
@@ -6,7 +6,7 @@
  * Copyright (c) 2005 Herbert Xu <herbert@gondor.apana.org.au>
  *
  * Portions derived from Cryptoapi, by Alexander Kjeldaas <astor@fast.no>
- * and Nettle, by Niels Möller.
+ * and Nettle, by Niels Möller.
  * 
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the Free

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 565 bytes --]

--- linux-2.6.21-rc7-git4.orig/include/linux/crypto.h	2007-04-20 20:22:13.000000000 -0400
+++ linux-2.6.21-rc7-git4.mod/include/linux/crypto.h	2007-05-03 07:09:47.000000000 -0400
@@ -6,7 +6,7 @@
  * Copyright (c) 2005 Herbert Xu <herbert@gondor.apana.org.au>
  *
  * Portions derived from Cryptoapi, by Alexander Kjeldaas <astor@fast.no>
- * and Nettle, by Niels Möller.
+ * and Nettle, by Niels Möller.
  * 
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the Free

Re: [PATCH] crypto: convert crypto.h to UTF-8

[Arne Georg Gleditsch]

"John Anthony Kazos Jr." <jakj@j-a-k-j.com> writes:
> Did this file individually, per request. Will re-do the whole tree later 
> as I'm still working on my handy-dandy testing and patching tools and 
> don't have a lot of time outside of work until the summer gets underway.

While this is probably inevitable, it would be nice if there was some
way to determine the actual coding system used for individual files.
Especially if we're mixing latin1 and utf8 in the same tree.  Has
something like adding "/* -*- coding: utf-8; -*- */" or similar to the
top of converted files been considered?

-- 
								Arne.

Re: [PATCH] crypto: convert crypto.h to UTF-8

[John Anthony Kazos Jr.]

> > Did this file individually, per request. Will re-do the whole tree later 
> > as I'm still working on my handy-dandy testing and patching tools and 
> > don't have a lot of time outside of work until the summer gets underway.
> 
> While this is probably inevitable, it would be nice if there was some
> way to determine the actual coding system used for individual files.
> Especially if we're mixing latin1 and utf8 in the same tree.  Has
> something like adding "/* -*- coding: utf-8; -*- */" or similar to the
> top of converted files been considered?

There's no reason for any non-UTF-8 to be in the tree at all, so 
eventually it won't be a problem. I'm (slowly but surely) working on 
converting everything in the tree. GCC handles UTF-8 just fine, and all 
non-stupid/non-broken distributions of GNU/Linux and other major Un*ces 
should be based on (or at least compatible with) UTF-8 in basic 
operations. Files like the keymaps will be more work to convert, but they 
can be as well.

I'm operating on the assumption that anything in the tree that isn't UTF-8 
is ISO-8859-1. Of course, I'm also checking it by hand to make sure a 
small-O-with-umlaut doesn't become the Klingon logo...

Besides, based on the actual binary representation of UTF-8, it's 
extremely unlikely for any ISO-8859-1 string to be detected as UTF-8. VIm 
already does this: UTF-8 it handles natively, but open up one of these 
unpatched files in VIm and you'll see "[converted]" at the bottom of your 
screen. Should happen if you open the attached .patch.bin file in VIm.

Re: [PATCH] crypto: convert crypto.h to UTF-8

[Arne Georg Gleditsch]

"John Anthony Kazos Jr." <jakj@j-a-k-j.com> writes:
> Besides, based on the actual binary representation of UTF-8, it's 
> extremely unlikely for any ISO-8859-1 string to be detected as UTF-8. VIm 
> already does this: UTF-8 it handles natively, but open up one of these 
> unpatched files in VIm and you'll see "[converted]" at the bottom of your 
> screen. Should happen if you open the attached .patch.bin file in VIm.

Yes, I agree that heuristics can be used to determine the coding
system used with a high degree of probability.  I'm just suggesting we
make the coding system explicit, in order to spare other applications
that do visual presentation of Linux source code having to perform
their own heuristics.

But hey, if I'm the only one wanting to see this particular bike shed
painted blue...

-- 
								Arne.

Re: [PATCH] crypto: convert crypto.h to UTF-8

[John Anthony Kazos Jr.]

> > Besides, based on the actual binary representation of UTF-8, it's 
> > extremely unlikely for any ISO-8859-1 string to be detected as UTF-8. VIm 
> > already does this: UTF-8 it handles natively, but open up one of these 
> > unpatched files in VIm and you'll see "[converted]" at the bottom of your 
> > screen. Should happen if you open the attached .patch.bin file in VIm.
> 
> Yes, I agree that heuristics can be used to determine the coding
> system used with a high degree of probability.  I'm just suggesting we
> make the coding system explicit, in order to spare other applications
> that do visual presentation of Linux source code having to perform
> their own heuristics.
> 
> But hey, if I'm the only one wanting to see this particular bike shed
> painted blue...

In any other case, I would agree completely, but like I said, the entire 
tree will be one encoding anyway, which will be UTF-8. Many tools would 
already have these heuristics, and even if they don't, the code itself 
will be perfectly legible no matter which encoding is used to view it, and 
only some things like circuit diagrams and peoples' names may be slightly 
mangled. Any byte which is 0x7F or less is identical in both encodings, so 
all normal ASCII is unchanged.

It's an issue only in transition. No new non-UTF-8 patches should be 
accepted, of course. And I won't be doing any changes that break anything 
other than a live person reading it and wondering why it looks weird if 
they don't have the right tools.

A line in <Documentation/CodingStyle> explicitly requiring UTF-8 sounds 
like a good idea. I shall submit one later if I remember. Many mail 
clients do this conversion automatically, which causes me headaches and 
requires me to attach the patches separately. Quite annoying really. I'm 
exploring the possibility of hacking together a simple SMTP client if 
that'll help me with these fool binary patches.

Or maybe setting up a little mini git repository with UTF-8 changes is a 
good idea? Hmm, I'll research that, and try it. Then I could just cc it to 
trivial and the list and they can just pull it in one go. One more week 
until summer vacation! I shall have time to do this then.

Re: [PATCH] crypto: convert crypto.h to UTF-8

[Jan Engelhardt]

On May 3 2007 09:21, John Anthony Kazos Jr. wrote:
>
>There's no reason for any non-UTF-8 to be in the tree at all, so 
>eventually it won't be a problem. I'm (slowly but surely) working on 
>converting everything in the tree. GCC handles UTF-8 just fine, and all 

In fact, GCC gives a crap about comments :)
and otherwise sees things as octets, not characters.
I think GCJ is the only one that really pays attention to encoding.

>non-stupid/non-broken distributions of GNU/Linux and other major Un*ces 
>should be based on (or at least compatible with) UTF-8 in basic 
>operations. Files like the keymaps will be more work to convert, but they 
>can be as well.
>
>I'm operating on the assumption that anything in the tree that isn't UTF-8 
>is ISO-8859-1. Of course, I'm also checking it by hand to make sure a 
>small-O-with-umlaut doesn't become the Klingon logo...

This is probably all you'll ever see:
http://lkml.org/lkml/2007/1/8/222


Jan
-- 

Re: [PATCH] crypto: convert crypto.h to UTF-8

[John Anthony Kazos Jr.]

> >There's no reason for any non-UTF-8 to be in the tree at all, so 
> >eventually it won't be a problem. I'm (slowly but surely) working on 
> >converting everything in the tree. GCC handles UTF-8 just fine, and all 
> 
> In fact, GCC gives a crap about comments :)
> and otherwise sees things as octets, not characters.
> I think GCJ is the only one that really pays attention to encoding.

The changes to the keymap files and so forth aren't quite as simple 
though. Have to convert the latin1 characters within character-constant 
expressions to \0 notation, while the comments can be left as utf8.

> >non-stupid/non-broken distributions of GNU/Linux and other major Un*ces 
> >should be based on (or at least compatible with) UTF-8 in basic 
> >operations. Files like the keymaps will be more work to convert, but they 
> >can be as well.
> >
> >I'm operating on the assumption that anything in the tree that isn't UTF-8 
> >is ISO-8859-1. Of course, I'm also checking it by hand to make sure a 
> >small-O-with-umlaut doesn't become the Klingon logo...
> 
> This is probably all you'll ever see:
> http://lkml.org/lkml/2007/1/8/222

Does this mean you're doing it and I'll be ignored, or that few people 
care and I'll be ignored? I figure if I just repost my patches to LKML 
once per month, they'll eventually get merged (or at least I'll get 
comments on how people actually want them). Things are tough on a 
high-volume list. I think the git method may have the best chance of 
success. We'll see.

Re: [PATCH] crypto: convert crypto.h to UTF-8

[Jan Engelhardt]

On May 3 2007 11:35, John Anthony Kazos Jr. wrote:
>
>> >non-stupid/non-broken distributions of GNU/Linux and other major Un*ces 
>> >should be based on (or at least compatible with) UTF-8 in basic 
>> >operations. Files like the keymaps will be more work to convert, but they 
>> >can be as well.
>> >
>> >I'm operating on the assumption that anything in the tree that isn't UTF-8 
>> >is ISO-8859-1. Of course, I'm also checking it by hand to make sure a 
>> >small-O-with-umlaut doesn't become the Klingon logo...
>> 
>> This is probably all you'll ever see:
>> http://lkml.org/lkml/2007/1/8/222
>
>Does this mean you're doing it and I'll be ignored, or that few people 
>care and I'll be ignored?

Nah. I did a walkthrough once, and my discoveries were that
iso-8859-{2 .. 14} was a real minority if not nonexistant,
leaving you with almost obvious choices to guess what a file's
encoding is. If a name looks good, it must be UTF8 already.
Else try ISO-8859-1. If it still looks odd -- perhaps because
it's a weirdo character like "1/2" or it "does not sound right",
try cp437. etc.

> I figure if I just repost my patches to LKML 
>once per month, they'll eventually get merged (or at least I'll get 
>comments on how people actually want them). Things are tough on a 
>high-volume list. I think the git method may have the best chance of 
>success. We'll see.
>

Jan
--