patchmldonkey, a multi-networks file-sharing client - Patches: patch #3984, Make filename_conversions option...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #3984: Make filename_conversions option implementation safe

Submitter:  su_blanc <su_blanc>
Submitted:  Thu 05 May 2005 09:47:24 AM UTC
   
 
Category:  Bug fixes Priority:  9 - Immediate
Status:  Done Assigned to:  amorphous
Open/Closed:  Closed

Jump to the original submission

Mon 30 May 2005 09:03:41 PM UTC, comment #10: 

Applied 2005/05/30, file #4625 and file #4660

spiralvoice <spiralvoice>
Group administrator
Mon 30 May 2005 01:15:46 AM UTC, comment #9: 

IMHO we have to rename it considering that the default value of filename_conversion was set to [(228, "ae");(246, "oe");(252, "ue");(223, "ss");(196, "Ae");(214, "Oe");(220, "Ue");] in the previous CVS. thus (see https://savannah.nongnu.org/bugs/?func=detailitem&item_id=9102#comment19) if somebody already built mlnet with the previous CVS, we force the user to have a default list that may not be as per his needs. I don't think the majority of users know and will use this option.

su_blanc <su_blanc>
Group Member
Sun 29 May 2005 07:00:30 PM UTC, comment #8: 

Why should we rename it? It should continue to work just fine (if there wasn't an non-utf-8 char entered, and if that is the case the user needs to change that option anyway).

Amorphous <amorphous>
Sun 29 May 2005 06:44:52 AM UTC, comment #7: 

- rename filename_conversion in utf8_filename_conversion to avoid clash with the previous option
- the option becomes a (int * UTF8 string) list (of course ASCII strings remain valid)

su_blanc <su_blanc>
Group Member
Fri 27 May 2005 02:18:35 PM UTC, comment #6: 

Yes, that is what i though of.
I'm not sure if we should just replace UTF-8 chars with UTF-8 strings or UTF-8 sub-strings with UTF-8 strings or use regular expressions. I guess the last option doesn't support UTF-8, so i guess the second is best. But i would be fine with the first one, too.

Amorphous <amorphous>
Fri 27 May 2005 12:37:40 AM UTC, comment #5: 

I would like but I don't know exactly what you want to do with it...
canonize_basename operates currently as follows:
- replace chars in the string (can be any encoding) on users request with a (int8 * ascii string) list
- replace forbidden chars in the string as per OS ...
- convert the string to a string suitable for the locale with Charset.to_locale

do you want to change canonize_basename as follows:
- convert the string to an UTF-8 string
- replace chars in the UTF-8 string on users request with a (int uchar) list or (int UTF-8 string) list or (int * uchar list) list...
- replace forbidden chars in the string as per OS ...
- convert the string to a string suitable for the locale with Charset.to_locale



su_blanc <su_blanc>
Group Member
Thu 26 May 2005 04:38:21 PM UTC, comment #4: 

The LGPL explicitly states, that instead the GPL may be applied.
Did you already modify the filename_conversion patch to use these functions (as there is still the old patch attached)?

Amorphous <amorphous>
Wed 18 May 2005 09:57:09 AM UTC, comment #3: 

additional patch for Unicode character support.
Basically i did nothing except take the camomile code and modify it a little bit (from uTF8.ml file).

the modifications to the charset.ml are summarized as follows:
- type uchar (caml int = 31 bits)
- function utf8_get: get the nth unicode char from an utf8 string (will not work if the string is not UTF-8).
- function utf8_length: the number of Unicode characters contained in an *UTF-8* string
- function add_uchar: add one Unicode character to a Buffer.t (can be useful for char replacements in an UTF-8 string for example).
- the function to_locale has been modified to benefit these new functions.

Please check the possible license issues as camomile is LGPL before applying to CVS.

su_blanc <su_blanc>
Group Member
Sat 07 May 2005 05:42:22 AM UTC, comment #2: 

I think the way to do is to create unichar interface.
But i have to go through the unicode algorithm...
so then we can convert any char in an utf8 string (up to char = 0x0b111111 i think).

su_blanc <su_blanc>
Group Member
Fri 06 May 2005 10:26:33 PM UTC, comment #1: 

wouldn't it be good to support any conversion for any utf-8 char to any utf-8 string (or isn't that possible because of multi-byte chars)? perhaps i want to convert some japanese char to something or i want to convert ue to ΓΌ or anything similar...

Amorphous <amorphous>
Thu 05 May 2005 09:47:24 AM UTC, original submission:  

- make sure we use forbidden chars according to the OS
- make sure filename_conversions contain only ASCII strings and int8 integers.

su_blanc <su_blanc>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #8890:  safe_utf8_filename_conversions_option.patch added by su_blanc (3KiB - application/octet-stream - replace file #4568)
file #8844:  charset_fix.patch added by su_blanc (12KiB - application/octet-stream - complement to file #4568)
file #8797:  make_filename_conversions_safe.patch added by su_blanc (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 6 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-07-07 spiralvoice StatusNone Done
    Open/ClosedOpen Closed
2005-06-22 spiralvoice Assigned toNone amorphous
2005-05-29 su_blanc Attached File- Added safe_utf8_filename_conversions_option.patch, #4660
2005-05-18 su_blanc Attached File- Added charset_fix.patch, #4625
2005-05-05 su_blanc Attached File- Added make_filename_conversions_safe.patch, #4568

Back to the top

Powered by Savane 3.13-758e.
Corresponding source code