#6 Align ReallocatePool() parameters with EDK2?

[Pete Batard]

Hi Nigel,

I'm opening a Feature Request to find out whether we'd want to change the definition of gnu-efi's ReallocatePool() to align it with the EDK2.

Right now, gnu-efi has ReallocatePool() as follows (in misc.c):

VOID *
ReallocatePool (
    IN VOID   *OldPool,
    IN UINTN  OldSize,
    IN UINTN  NewSize
    )
 ~~~
On the other hand, the EDK2 has `ReallocatePool()` as (https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/MemoryAllocationLib.h#L407-L413):

VOID
EFIAPI
ReallocatePool (
IN UINTN OldSize,
IN UINTN NewSize,
IN VOID OldBuffer OPTIONAL
);
~~~

So the issue is that you can't interchange EDK2 and gnu-efi code that uses ReallocatePool() as the location of the old buffer/pool is different.

Of course, what one can do is define their own MyReallocatePool() macro that switches the order of parameters for code that they plan to use in either the EDK2 or gnu-efi, but this is rather inconvenient, and in the absolute, one would expect gnu-efi to be as close as possible to the EDK2 to avoid code incompatibilities.

So I am wondering what your views are on introducing a breaking change in gnu-efi that woul realign ReallocatePool() with the EDK2 definition. Obviously, that would mean that anyone currently using ReallocatePool() with gnu-efi would have to modify their code if they upgrade, which might be a deal breaker. On the other hand, it would ease an UEFI developer's life when using or interfacing with EDK2...

Regards,

/Pete

[Nigel Croxon]

I prefer to align with EDK2 definitions.

1 Option
Change the definitions over to match EDK2
Add a compile switch (non default) to use the old definition
Everyone breaks untill they change their code
This point foward we match EDK2 (default)

2 Option
Bump the major revision with the change to match EDK2.
I can handle having two branches now and slowly cut projects over to the new.
Version 3.x is non matching EDK2
Version 4.0 is matching EDK2

Thoughts?
-Nigel

[Pete Batard]

Personally, my vote would be for Option 1, especially as I think the compiler switch is a sensible way to handle potential recriminations, but I understand that some developers may still scream bloody murder with anything but Option 2.

I actually used to be in that second camp until the day I had to use a library that broke its APIs from one version to the next (and this one didn't even have the benefit of providing a compiler option for the old API usage). But I understand that "enlightenment" with regards to how genuine of a concern API breakage really is might be hard to come by, so I wouldn't mind hearing the opinion of other gnu-efi users...

/Pete