runtime: runtime.Caller returns always '/' separator in file paths on Windows

[gopherbot]

by pkorotkov:

What steps will reproduce the problem?
1. Call function runtime.Caller(...)
2. Take the file path (second argument)

What is the expected output?
On Windows path separator is "\"

What do you see instead?
"/"

Which compiler are you using (5g, 6g, 8g, gccgo)?
8g

Which operating system are you using?
Windows 7, x86

Which revision are you using?  (hg identify)
0b67257c702f tip

[minux]

Comment 1:

Windows will accept both slash and backslash as path separator, so I think
this is a non-issue.
Leave it to others to decide.

[gopherbot]

Comment 2 by pkorotkov:

It's an issue if your business logic for the path is based on the assumption that one
has OS-specific path separators (os.PathSeparator); that's my case. Despite that you can
easily work around it's a bug anyway.

[dsymonds]

Comment 3:

Labels changed: added priority-go1, packagebug, removed priority-triage.

[alexbrainman]

Comment 4:

Filenames returned by runtime.Caller do have / as path delimiter. They are extacted from
symtab of compiled packages. They are written by compiler when it compiles package.
As far as I remember, compiler rewrites all \ into / because all our runtime procedures
expect / as path delimiter. I am not sure it is safe to change compiler to leave \ alone.
Alternatively, we could change runtime.Caller to rewrite all / into \ if running on
windows. I am not sure what the implications are. It could also be misleading sometimes,
if, for example, some packages where compiled on unix and then copied onto windows.
/home/my/file.go would then become \home\my\file.go.
Alex

[gopherbot]

Comment 5 by pkorotkov:

Alex, your example of misleading paths is valid only in a cross-compiling case. I see
two obvious options:
1. Leave it as is and add a relevant comment to the func's spec;
2. Force all path separators to be replaced with OS-specific ones indicating such
behavior in the func's spec as well. If source code is available, it's correct 'ab
incunabulis'. If not - file was cross-compiled - you just need to do little extra work
to get right paths.
Maybe, it would be nice to have automatic src-detection in this context... don't know. 
In either case, current version of function description lacks for clarifications.

[gopherbot]

Comment 6 by pkorotkov:

Alex, your example of misleading paths is valid only in cross-compiling case. I see two
obvious options:
1. Leave it "as is" and add a relevant comment to the func's spec;
2. Force all path separators to be replaced with OS-specific ones indicating such
behavior in the func's spec as well. If source code is available, it's correct 'ab
incunabulis'. If not - file was cross-compiled - you just need to do little extra work
to get the right paths.
Maybe, it would be nice to have automatic src-detection in this context... don't know. 
In either case, the current version of the function description lacks for clarifications.

[rsc]

Comment 7:

We can revisit this after Go 1.

Labels changed: added priority-later, removed priority-go1.

Status changed to Accepted.

[rsc]

Comment 8:

Labels changed: added go1.1maybe.

[rsc]

Comment 9:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

[rsc]

Comment 10:

I think as part of Go 1.3 we will change the way line numbers are sent out of the
compilers, and they will record the full OS path. Then everything will work as expected.

Labels changed: added go1.3.

[robpike]

Comment 11:

Labels changed: removed go1.3.

[rsc]

Comment 12:

Labels changed: added go1.3maybe.

[rsc]

Comment 13:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 14:

Labels changed: added repo-main.