Add note about Issue 7648 to std.stdio.File.

[denis-sh]

Issue URL: http://d.puremagic.com/issues/show_bug.cgi?id=7648

IMHO, this note must be added as the issue is unexpected and may result in big troubles for someone.

[denis-sh]

An apology: I did my best to use _w* C functions but underlying bug in C runtime prevents it from work correct. I also tried to rewrite the module using WinAPI but had to abandon the work (temporary I hope) because of lack of time.

[denis-sh]

Two weeks ping.

[ghost]

If there's an issue with Unicode in File, shouldn't we try to fix the bug?

[denis-sh]

shouldn't we try to fix the bug?

As I told, I did my best.

12 years of having silently incorrectly working in some case which are relatively hard to predict in debugging main file IO functionality is inexcusable.

The main issue it that we use C runtime which is full of undocumented implementation defined features and even experienced coders often can't do very simple things with C runtime (see Phobos for examples of how one mustn't use C runtime and see druntime for examples of how one must use C runtime).

[dnadlinger]

Pinging @andralex.

[denis-sh]

Pinging Andrei The Destructor

Circle dependency detected! Andrei doesn't code for Windows and asks others to revise such pulls.

[andralex]

Yes, I wouldn't have much to comment. On the face of it, if it's a documentation note that makes technical sense, I'm all for it. I'll merge now, please amend as necessary.

[dnadlinger]

I was just worried about basically telling people not to use File on Windows.

[DmitryOlshansky]

Better then letting them shoot their feet off I guess.
All in all I expect this issue to be specific for DMC run-time, isn't it?
MSVC 64-bit run-time might work then.

[denis-sh]

MSVC 64-bit run-time might work then.

AFAIK, MSVC doesn't have such issues. So it will work if my (never tested) fix is correct.

[DmitryOlshansky]

What I believe that means is that we basically need a proper (modern and open-source) run-time for Win32 then.
I've been toying with one myself but aside from basics I haven't gone far. The plan was to make a feather-weight run-time by doing a very thing wrapping of WinAPI. Thus malloc was just mapped to HeapAlloc and so on.

In the long run I think 32-bit Windows systems are here to stay for a few years at least (with Windows on ARM devices if not x86) even if the most of the "market" is going to 64 bit.

[ghost]

Isn't it better to use e.g. transcode from std.encoding internally in File on Windows rather than saying "don't use File"?

[denis-sh]

Isn't it better to use e.g. transcode from std.encoding internally in File on Windows rather than saying "don't use File"?

You are proposing to make failures even less debugable as it will just fix some random cases where it is possible to represent a UTF8 string via CP_ACP.

[ghost]

You are proposing to make failures even less debugable as it will just fix some random cases where it is possible to represent a UTF8 string via CP_ACP.

And how is your comment on the function debuggable? And what is the alternative the user should look into if they want to use files?

AFAIK transcode should throw an exception if a string can't be represented in some encoding.

[denis-sh]

And how is your comment on the function debuggable?

One have to read documentation about stuff he use. So he will not hit the issue.

And what is the alternative the user should look into if they want to use files?

Written in the note.

AFAIK transcode should throw an exception if a string can't be represented in some encoding.

I mean you propose to increase amount of cases the function will work correct by accident. It is unacceptable. If the function is fundamentally broken it must be documented appropriately and not used.

[ghost]

I mean you propose to increase amount of cases the function will work correct by accident.

I proposed we call transcode internally, which (if I'm not mistaken) will throw an exception if a string can't be converted to another encoding. Where's the accident?

Written in the note.

Thanks, I didn't notice. Note however that the generated doc line is a bit broken, this is what I'm getting:

One can use std.file.read/std.file.write/File">std.stream.File instead. 

If the function is fundamentally broken it must be documented appropriately and not used.

It should be fixed, people have been using File for ages. Something as fundamental as this File structure should work in a standard library.

[denis-sh]

proposed we call transcode internally, which (if I'm not mistaken) will throw an exception if a string can't be converted to another encoding. Where's the accident?

I mean the case passed string is convertible is an accident.

Note however that the generated doc line is a bit broken, this is what I'm getting:

Works for me.

It should be fixed,

You are welcome!

people have been using File for ages.

Doesn't matter. std.stdio.File was broken for ages in different ways. If one used it, he didn't care about his program stability.

Something as fundamental as this File structure should work in a standard library.

Being a constant and happy D user, I can tell that it isn't an issue at all in current language state as there are more serious problems (like the fact you program can accidentally become unable to build because of any change or wrong code bugs).

[ghost]

I mean the case passed string is convertible is an accident.

Using transcode internally will not change this. It will only ensure an exception is thrown if it can't be converted.

The real accident is passing a string which isn't converted and ends up being interpreted as something else by the OS, possibly leading to things like opening the wrong file (or worse, deleting a file if the File was opened with the w switch).

[alexrp]

In the long run I think 32-bit Windows systems are here to stay for a few years at least (with Windows on ARM devices if not x86) even if the most of the "market" is going to 64 bit.

Right, but Windows on ARM will not use DMC's runtime.

[DmitryOlshansky]

In the long run I think 32-bit Windows systems are here to stay for a few years at least (with Windows on ARM >>devices if not x86) even if the most of the "market" is going to 64 bit.
Right, but Windows on ARM will not use DMC's runtime.

Hence what I told above all was:

What I believe that means is that we basically need a proper (modern and open-source) run-time for Win32 then.

I know there are some shortcomings with using M$ run-time such as not being able to control how they change it (nor easily update towards newer versions). Even current Win64 version could cause us some grief later on.

I'd be crazy enough to suggest basically taking Musl (UTF-8 only smallish and neat C run-time for Linux) and porting the "syscall" part over to WinAPI. And I'd gladly lend a hand anyone trying this ;)