Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Allow BitConverter.ToString to format without dashes #14014

Closed
nvivo opened this issue Jan 24, 2015 · 18 comments
Closed

Allow BitConverter.ToString to format without dashes #14014

nvivo opened this issue Jan 24, 2015 · 18 comments
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Runtime help wanted [up-for-grabs] Good issue for external contributors
Milestone

Comments

@nvivo
Copy link

nvivo commented Jan 24, 2015

I think BitConverter is not even in CoreFx yet, but for when it is, please allow to convert to an hex string without dashes. This is to avoid this pattern:

BitConverter.ToString(data).Replace("-", string.Empty);

This representation of bytes is common enough that .NET should have a simple method to do this without extra code or an extra memory allocation.

@ebickle
Copy link

ebickle commented Feb 2, 2015

BitConverter needs a lot of work, potentially a new API altogether. It's once place that desperately needs both Little Endian and Big Endian support. The number of hack solutions on StackOverflow with people trying to flip the order of their byte arrays before calling BitConverter methods is truly frightening.

@zii-dmg
Copy link

zii-dmg commented Feb 2, 2015

Maybe .NET Core should include DataConverter class from Mono?

@Eirenarch
Copy link

I agree with @ebickle . I just ran into the little endian vs big endian issue 2 days ago. Also I think we should have a way to convert a hex string to a byte array. I mean the Convert class has methods to convert to/from base64 but for hex you have to roll your own method and it makes no sense to me.

@CodesInChaos
Copy link

I'd add these methods to Convert:

public static string ToHexStringUpper(byte[] data);
public static string ToHexStringLower(byte[] data);
public static byte[] FromHexString(string hexString);

I'd also consider having them return null when the argument is null since that simplifies printing byte arrays that may be null.

@felipepessoto
Copy link
Contributor

Hi, I'll work on it.
@karelz would you assign me please?

@karelz
Copy link
Member

karelz commented Dec 14, 2016

The API is not approved yet, so we won't assign it to anyone.

Next step: We need formal API proposal.

@andreujuanc
Copy link

+1 to this. So simple yet really good.

@danmoseley
Copy link
Member

@andreujuanc do you want to take a shot at formalizing the format? Link to a good example from this doc.
https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md

@andreujuanc
Copy link

@danmosemsft Sure. But I would like to have a small discussion if possible. Gitter, slack, or should we keep everything in here?

@danmoseley
Copy link
Member

We tend to keep stuff in here because otherwise it doesn't scale well. If you have alternatives or other proposals etc feel free to share them here or pick one suggestion for others to give feedback.

@mpollock11p
Copy link

I'm new at this but this sure helped out a hole lot! I was trying to get a whole packet out and don't know why anyone would even want the dashes in there?? Thanks much!!

@jeremyVignelles
Copy link

Is it a duplicate of dotnet/corefx#10013 or am I missing something?
That issue has a formal API defined and offers methods for the reverse conversion.

@mfalkvidd
Copy link

mfalkvidd commented Apr 10, 2019

@jeremyVignelles dotnet/corefx#10013 was created 1.5 years after this issue was created, and has a significantly larger scope. The larger scope might delay implementation and might therefore be a less desirable solution. But if dotnet/corefx#10013 was implemented, it would solve this issue as well.

@stephentoub
Copy link
Member

@mfalkvidd, valid concerns. At the same time, more recent forward progress has been made on that issue and not on this one, and we don't need two issues covering the same scope, so I'm going to close that one. Thanks, all.

@mfalkvidd
Copy link

20 days ago the "api-ready-for-review" label was removed from 10013, calling for a survey to be conducted. Since then it seems like nothing has happened. That doesn't sound like forward progress to me ;-)

But if you can make things happen in 10013, please do. I'm just worried it will be mothballed.

@stephentoub
Copy link
Member

That doesn't sound like forward progress to me

It's been looked at and talked about, leading to that status change. That's more than had happened here.

I'm just worried it will be mothballed

If it doesn't happen, this one wouldn't either. Deciding to go ahead with an issue doesn't mean it's done exactly as outlined; it effectively represents a desire to explore the space further, whch could mean doing more or less than is described, or something different entirely.

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 5.0 milestone Jan 31, 2020
@alrz
Copy link
Member

alrz commented Jun 10, 2020

This is a dead link dotnet/corefx#10013 and I couldn't find the issue in runtime repo.

@danmoseley
Copy link
Member

10013 is https://github.com/dotnet/corefx/issues/10013 which redirects to #17837

@ghost ghost locked as resolved and limited conversation to collaborators Jan 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Runtime help wanted [up-for-grabs] Good issue for external contributors
Projects
None yet
Development

No branches or pull requests