Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

String.Join(string, object[]) bug when first item is null #5681

Closed
GSPP opened this issue Apr 22, 2016 · 17 comments
Closed

String.Join(string, object[]) bug when first item is null #5681

GSPP opened this issue Apr 22, 2016 · 17 comments
Assignees
Milestone

Comments

@GSPP
Copy link

GSPP commented Apr 22, 2016

Continuing my series to break the BCL for fun and no profit here's another string.Join bug:

String.Join(",", new object[] { null, "x" })

returns "". It should return ",x".

This bug exists in CoreCLR, in 4.6.2 and in the recently merged string.Join fix.

@bbowyersmyth
Copy link
Contributor

It's a documented bug so that makes it a feature 😉
https://msdn.microsoft.com/en-us/library/dd988350(v=vs.110).aspx

@jkotas What is the viewpoint on quirking old bugs on the new core platforms?

@jkotas
Copy link
Member

jkotas commented Apr 22, 2016

It is case by case.

cc @AlexGhiondea

@GSPP
Copy link
Author

GSPP commented Apr 22, 2016

@bbowyersmyth oh no! Haha that is so unfortunate.

@jamesqo
Copy link
Contributor

jamesqo commented May 21, 2016

IMO I think this should be fixed for .NET Core; this behavior is unintuitive, especially considering the fact that if you cast to IEnumerable<object> (or cast to object[] from string[], since arrays are covariant) you will get different behavior. This makes it very hard to write technically correct code.

@jamesqo
Copy link
Contributor

jamesqo commented Nov 2, 2016

@jkotas, you mentioned in the Tuple PR that commits that may cause compatibility issues with the desktop are simply not cherry-picked. Would it make sense to remove the bug now and fix the documentation? (It is preventing me from sharing code with the new char-based Join overloads-- see dotnet/coreclr#7942 (comment)

@jkotas
Copy link
Member

jkotas commented Nov 3, 2016

I do not have an option on this one.
@stephentoub Do you happen to know about similar examples in corefx, to see where we are setting the bar on issues like this one?

@stephentoub
Copy link
Member

@stephentoub Do you happen to know about similar examples in corefx, to see where we are setting the bar on issues like this one?

I thought I responded to this a few weeks ago, but apparently my comment didn't take. I don't really know of similar examples. We've certainly taken bug fixes that haven't yet been ported back to desktop. But we've also avoided making some kinds of fixes when the benefit is very low and the observable difference could cause cross-platform compatibility issues, e.g. throwing an ArgumentOutOfRangeException instead of an IndexOutOfRangeException.

I similarly don't have a strong opinion on this particular case. This behavior is documented, which is unfortunate, but it's also quite strange and inconsistents, e.g. that these two Console.WriteLine calls output different results:

var args = new[] { null, "x" };
Console.WriteLine(string.Join(",", (object[])args));
Console.WriteLine(string.Join(",", (string[])args));

so I'd be ok seeing it fixed as long as it was ported back to desktop.

@AlexRadch
Copy link
Contributor

@stephentoub This behavior is documented in note as issue and have number of workarounds.

@danmoseley
Copy link
Member

This was fixed in dotnet/coreclr#8114.

@weshaggard
Copy link
Member

@AlexGhiondea we don't have the netfx tags in the coreclr repo what is the best way to get this tracked for desktop?

@AlexGhiondea
Copy link
Contributor

AlexGhiondea commented Nov 18, 2016

@weshaggard the easiest way is to create an issue in the CoreFx repo and tag that with Netfx-port-consider.

@weshaggard
Copy link
Member

@AlexGhiondea we should probably do that for this issue if we haven't already.

@AlexGhiondea
Copy link
Contributor

AlexGhiondea commented Nov 21, 2016

I have tagged dotnet/corefx#14083 with netfx-port-consider.

@karelz
Copy link
Member

karelz commented Nov 29, 2016

Updated PR # in @AlexGhiondea's comment to the new one (dotnet/corefx#14083).

@AlexRadch please consider all impact of your PR switches in future.

@danmoseley
Copy link
Member

I see no use for this issue. fixed by dotnet/corefx#13747

@danmoseley
Copy link
Member

Oh, it was clsoed already. My bad

@jayaranigarg
Copy link

@danmosemsft : Is this ported to netfx yet?

@msftgits msftgits transferred this issue from dotnet/coreclr Jan 30, 2020
@msftgits msftgits added this to the Future milestone Jan 30, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Jan 1, 2021
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

No branches or pull requests