This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
Max gerrit-no-reply at lists.osmocom.orgMax has posted comments on this change. ( https://gerrit.osmocom.org/12492 )
Change subject: LCLS: add string dump helpers
......................................................................
Patch Set 10:
(4 comments)
Hopefully latest revision clarifies the rest. Don't hesitate to get in touch if that's not the case.
https://gerrit.osmocom.org/#/c/12492/7/src/gsm/gsm0808_utils.c
File src/gsm/gsm0808_utils.c:
https://gerrit.osmocom.org/#/c/12492/7/src/gsm/gsm0808_utils.c@614
PS7, Line 614: * \param[in] lcls pointer to the struct to print, used as talloc context to hang the result off.
> I've done this type of thing before, and most of the time it turns out to be impractical.
Sorry to hear that but I don't see how it's related to this case.
> I'd suggest returning a static string buffer that doesn't need freeing.
I don't see any practical advantages in that: most of the time talloc will clean it up alongside with lcls automatically.
> but you avoid leaking strings
Where? I don't see any leaks. Could you be more specific?
> and you can guarantee a non-NULL return arg
Why would we want such a guarantee?
> Hence can directly include in printf() args.
I haven't found any docs explicitly allowing or forbidding printf("%s", NULL); in practice it will just print '(null)'. Are you sure we're not supposed to pass NULL pointer to printf()?
https://gerrit.osmocom.org/#/c/12492/7/src/gsm/gsm0808_utils.c@618
PS7, Line 618: char *s = NULL;
> Seeing this for the first time. […]
Embedded arch won't have talloc available. It's also not expected to deal with LCLS to begin with.
https://gerrit.osmocom.org/#/c/12492/7/src/gsm/gsm0808_utils.c@624
PS7, Line 624: #if (!EMBEDDED)
> In this current form, this is leaking the talloc string from osmo_gcr_dump().
> Of course will be cleaned up as soon as the struct osmo_lcls is deallocated
That seems to be self-contradictory: if smth is leaked it means that it'll never be deallocated. If it's deallocated than it's not leaked.
https://gerrit.osmocom.org/#/c/12492/7/tests/gsm0808/gsm0808_test.c
File tests/gsm0808/gsm0808_test.c:
https://gerrit.osmocom.org/#/c/12492/7/tests/gsm0808/gsm0808_test.c@746
PS7, Line 746: printf("\t%s\n", osmo_gcr_dump(lcls_out));
> Some of our unit tests fail from the address sanitizer noticing non-deallocated buffers.
Which ones? I thought we have sanitizer enabled by default so it'd cause jenkins failure.
--
To view, visit https://gerrit.osmocom.org/12492
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Ic3609224c8f3282d667e75f68bc20327e36eb9e6
Gerrit-Change-Number: 12492
Gerrit-PatchSet: 10
Gerrit-Owner: Max <msuraev at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Max <msuraev at sysmocom.de>
Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Comment-Date: Mon, 21 Jan 2019 15:36:15 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190121/eff00df6/attachment.htm>