Attention is currently required from: pespin. laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/36076?usp=email )
Change subject: osmo_io: Add osmo_io_get_ioops() function ...................................................................... Patch Set 1: (1 comment) File include/osmocom/core/osmo_io.h: https://gerrit.osmocom.org/c/libosmocore/+/36076/comment/4c518b00_3d5c1975 PS1, Line 112: void osmo_iofd_get_ioops(struct osmo_io_fd *iofd, struct osmo_io_ops *ioops); > It may make more sense to return a "const struct osmo_io_ops*" so that no > copy is needed by default. […] If you want to make it generic, it would probably be best to decoupple the segmentation callback from the other callbacks, or even all of the callbacks from each other. That way there wouldn't be any shared struct between the lib and applications. Using a const pointer doesn't really guarantee that the user won't be able to modify the instance of the struct used/owned by the library. The user can just type-cast it to non-const and then overwrite library data. The copy avoids that. Regarding struct size: The application and lib already need to agree on this, as the set_io_ops operating also uses that very same struct. So if they need to agree on the "set" side, it is not a problem if the same assumption holds true for the "get" -- To view, visit https://gerrit.osmocom.org/c/libosmocore/+/36076?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: libosmocore Gerrit-Branch: master Gerrit-Change-Id: I03398c811b9534f50c6644b21eea89a04be29fb0 Gerrit-Change-Number: 36076 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <[email protected]> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <[email protected]> Gerrit-Attention: pespin <[email protected]> Gerrit-Comment-Date: Wed, 28 Feb 2024 09:14:48 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <[email protected]> Gerrit-MessageType: comment
