> On Jul 7, 2016, at 1:27 PM, Marvin H?user <[email protected]> wrote: > > Hey Bruce, > > Sorry if I am wasting your time, but where exactly is the problem? > > I don't think these strings can ever be statically allocated. If pointers to > stack variables were used, the strings would be theoretically invalid the > moment the exposing function returns. Furthermore they can't be part oft he > struct itself as that would change the offsets of all other members after the > string. Hence I think it can be concluded they are always dynamically > allocated. > And as one can be sure they are dynamically allocated, I think it's the task > of the function that uninstalls the protocol to free the two buffers. Should > the protocol not be uninstalled till ExitBootServices(), it doesn't matter > either because the OS loader may treat Boot Services code and data as free > space. > > Did I miss something? >
Marvin, I think your logic is sound in general. A protocol's structure could be a global or malloc'ed and as long as the protocol is installed that data exists. You only need to clean up that data if the protocol is uninstalled from the handle. Bruce is asking about a protocol member function that returns a data structure into a caller allocated buffer (hopefully I got that right) that contains pointers to other items. So conceptually it could be a different malloc'ed buffer leaked on every call? So I think it is a less clear cut case. Thanks, Andrew Fish > Regards, > Marvin. > >> -----Original Message----- >> From: edk2-devel [mailto:[email protected]] On Behalf Of >> Bruce Cran >> Sent: Thursday, July 7, 2016 9:36 PM >> To: [email protected] >> Subject: [edk2] Firmware Management Protocol: CHAR16* fields in >> EFI_FIRMWARE_IMAGE_DESCRIPTOR >> >> Before I go hassling the USWG, I thought I'd check here in case anyone >> knows. >> >> In the Firmware Management Protocol introduced in UEFI 2.3, there's a >> EFI_FIRMWARE_IMAGE_DESCRIPTOR structure that has two CHAR16* fields, >> 'ImageIdName' and 'VersionName'. The UEFI spec doesn't say anything >> about memory allocation, but they're strings that at least in our driver are >> dynamically allocated. >> >> Since there's no FMP 'cleanup' function, I'm wondering if there was some >> sort of mistake specifying those, because I don't see a way to avoid leaking >> memory. >> >> -- >> Bruce Cran >> _______________________________________________ >> edk2-devel mailing list >> [email protected] >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
