Added basic implementation for NSString contentsOfURL:usedEncoding:

[mohitathwani]

In NSString, for contentsOfURL:usedEncoding: checking the BOM of the received data and determining whether encoding to be used should be UTF 16 BE or UTF 16 LE

[alblue]

This has a guard here, but uses enc! in the dereferencing of the pointer. It would make sense to have let enc = enc, cf = ... enc, so that if enc isn't passed then we don't blow up the process.

[alblue]

Indentation looks off by one character on this line.

[parkera]

@swift-ci please test

[mohitathwani]

@swift-ci please test

[parkera]

@swift-ci please test

[zmeyc]

 +        let bytePtr = readResult.bytes.bindMemory(to: UInt8.self, capacity:readResult.length)
 +        if bytePtr[0] == 254 && bytePtr[1] == 255 {
 +          enc?.pointee = String.Encoding.utf16BigEndian.rawValue
 +        }

If readResult.length is less than 2, unitialized memory will be referenced.

And a possible memory leak: cf is created by CFStringCreateWithBytes, but not released when exitting on errors. AFAIK ARC doesn't handle this?

[mohitathwani]

@zmeyc I thought about that too but there is an else which sets the default encoding to UTF8 and proceed to try decoding the file which could be less than 2 bytes with UTF 8 encoding.

[zmeyc]

@mohitathwani Referencing unitialized memory is undefined behavior, it will trigger tools like valgrind, unitialized memory can contain BOM with wrong byte order etc. I propose checking the length before analyzing these two bytes for BOM.

[mohitathwani]

@zmeyc Updated the code with your suggestion.
@parkera could you please trigger a test?

[parkera]

@swift-ci please test

[mohitathwani]

Thanks @parkera ! Do you think this is merge worthy?

[parkera]

Looks good, thanks!