On Tuesday, September 15, 2020 9:41 AM, Jan Beulich wrote:
> On 14.09.2020 17:05, Trammell Hudson wrote:
> > [...] I checked to see
> > which functions would need to be wrapped. It is a surprisingly
> > small number:
> > #define PrintStr(s) StdOut->OutputString(StdOut, (CHAR16 *)(s))
> > #define P
On 14.09.2020 17:05, Trammell Hudson wrote:
> On Monday, September 14, 2020 10:55 AM, Jan Beulich wrote:
>> On 14.09.2020 16:46, Trammell Hudson wrote:
>>> Option 3 would be to write wrappers for the few functions that are
>>> used in the EFI boot path that cast-away the constness of their
>>> arg
On Monday, September 14, 2020 10:55 AM, Jan Beulich wrote:
> On 14.09.2020 16:46, Trammell Hudson wrote:
> > Option 3 would be to write wrappers for the few functions that are
> > used in the EFI boot path that cast-away the constness of their
> > arguments (while also silently cursing the UEFI fo
On 14.09.2020 16:46, Trammell Hudson wrote:
> On Monday, September 14, 2020 10:30 AM, Jan Beulich wrote:
>> On 14.09.2020 16:25, Trammell Hudson wrote:
>>> By defining IN as const, the EFI handler functions become almost
>>> const-correct and allow most of the rest of the EFI boot code to
>>> use
On Monday, September 14, 2020 10:30 AM, Jan Beulich wrote:
> On 14.09.2020 16:25, Trammell Hudson wrote:
> > By defining IN as const, the EFI handler functions become almost
> > const-correct and allow most of the rest of the EFI boot code to
> > use constant strings.
>
> How does this work with c
On 14.09.2020 16:25, Trammell Hudson wrote:
> By defining IN as const, the EFI handler functions become almost
> const-correct and allow most of the rest of the EFI boot code to
> use constant strings.
How does this work with combined "IN OUT"? I'm afraid there is a
reason why things aren't done t
