Issue 81692 in fuchsia: Offer utility functions for converting fuchsia::net::MacAddress ↔ std::string

[jerem… via monorail]

Updates:
Cc: fidl-...@fuchsia.dev

Comment #3 on issue 81692 by jerem...@google.com: Offer utility functions for converting fuchsia::net::MacAddress ↔ std::string
https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=81692#c3

I idly wonder if this is something that the FIDL team wants to solve generically, rather than having something one-off for MacAddresses. For any FIDL struct or table, we could autogenerate utility libraries with reasonable defaults for things like equality testing, hash code generation, and string conversion operators. Users could override the default if there is a standard for how something is printed (as there is for MAC addresses). Adding fidl-dev for comment / thoughts.

--
You received this message because:
1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.fuchsia.dev/hosting/settings

Reply to this email to add a comment.

[peter… via monorail]

Updates:
Components: NetworkStack

Comment #4 on issue 81692 by peterj...@google.com: Offer utility functions for converting fuchsia::net::MacAddress ↔ std::string
https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=81692#c4

This doesn't solve it for C/C++, but in Rust, the [`fidl_fuchsia_net_ext::MacAddress`](https://fuchsia-docs.firebaseapp.com/rust/fidl_fuchsia_net_ext/struct.MacAddress.html) extension type implements `From<fidl_fuchsia_net::MacAddress>` and `Display`, so you can go from the FIDL MacAddress type → String that way.

I'm not sure if there is an equivalent available, but maybe there should be something similar for the C++ bindings.

[jerem… via monorail]

Comment #5 on issue 81692 by jerem...@google.com: Offer utility functions for converting fuchsia::net::MacAddress ↔ std::string
https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=81692#c5

Addendum: This request comes from an SDK customer, so whatever we do has to be surfaced in the SDK.

[ianl… via monorail]

Comment #6 on issue 81692 by ian...@google.com: Offer utility functions for converting fuchsia::net::MacAddress ↔ std::string
https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=81692#c6

We don't have any plans to offer the ability to customize string representations for particular types. We have long-term ideas about extending the FIDL language to be able to express this kind of thing but they're way off.

We already do generate reasonable default implementations for testing, hash code generation and string conversion, depending on the target language, but don't offer any ability to customize those behaviors.

I think of something like `fuchsia.net.MacAddress` as the Fuchsia equivalent of POSIX's `struct ether_addr`. POSIX provides `ether_ntoa()` and `ether_aton()` functions in libc but I don't think we have an answer for where such a function should live in Fuchsia.

One answer is that the netstack service could offer `MacAddressToString` and `MacAddressFromString` methods that programs should use when preparing MacAddress values for display to users and parsing MAC addresses that users present. This would allow the behavior to be shared across services, implemented once, and updated with the netstack implementation rather than the applications that use it. It would involve additional IPC round-trips but maybe fine - I don't think this would be needed in high-throughput, low-latency cases.

[bruno… via monorail]

Updates:
Labels: fireteam_triaged GoodFirstBug ns-apiti-task ns-cpa-task Pri-3 type-Enhancement
Status: Backlog

Comment #7 on issue 81692 by bruno...@google.com: Offer utility functions for converting fuchsia::net::MacAddress ↔ std::string
https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=81692#c7

Some questions
- Why stop at fuchsia::net::MacAddress? There's a number of types in fuchsia.net FIDL that have specific string representations (IPv4, IPV6 address, socket addresses).
- Is there prior art about something like this being part of the SDK? I'm somewhat reticent to add it, it feels like something that can be trivially achieved outside of the SDK. Feels like FIDL support library, which does have precedents in tree, but I'm not super familiar with SDK.
- The equivalent Rust library that peter mentioned in comment#4 does things like conversion from well-known types (inet structs in this case), that's also something that may be repeated N times by consumers.

Adding String conversion functions to FIDL protocols, as proposed by ianloic@ in comment#6 definitely feels like a pattern that we don't want to encourage, however. Can hardly justify the round trip time to another service for a string representation implementation that is available in libc.

Moving this go backlog.