Derive Default for Time

[Ayush1325]

Time cannot be a null pointer when passing to GetTime. Thus there needs
to be a default initialization.

Signed-off-by: Ayush Singh ayushsingh1325@gmail.com

[dvdhrm]

Time cannot be a null pointer when passing to GetTime. Thus there needs to be a default initialization.

Can you elaborate? How does a NULL-Pointer relate to default initialization?

I would imagine using GetTime() with MaybeUninit() and calling assume_init() once GetTime() returns with success?

Generally, I don't mind the Default implementation. However, did you check whether the spec references zero-initializing Time anywhere? Does it apply any meaning to it, like being Invalid?

[Ayush1325]

Under the Status Code Returned in GetTime(), this is preset:
EFI_INVALID_PARAMETER: Time is NULL.

This basically means that unless the Time parameter is initialized before being passed to the function, it well will just return an error. I also tried using it (Basically passing an uninitialized Time) and well, I got an error until I tried initializing a Time with everything 0 beforehand.

[dvdhrm]

Under the Status Code Returned in GetTime(), this is preset: EFI_INVALID_PARAMETER: Time is NULL.

This basically means that unless the Time parameter is initialized before being passed to the function, it well will just return an error.

Sorry, but this is not true. Your quote from the specification states that if you pass NULL, then EFI_INVALID_PARAMETER is returned. It does not talk about passing valid pointers to non-zeroed memory. The specification even has examples that call into GetTime() without clearing the memory. See 4.7.1 for instance. So according to the spec, this should work fine without clearing the Time structure.
Also, have a look at the 8.3 SetTime() definition. There the spec explicitly states that the function performs error-checking on the Time parameter ("Full error checking is performed on the different fields of the EFI_TIME structure")

Now this does not mean that implementations follow this. But it is a crucial difference whether the spec mandates something, or whether implementations violate the spec and we try to adapt.

I also tried using it (Basically passing an uninitialized Time) and well, I got an error until I tried initializing a Time with everything 0 beforehand.

This is really weird. So you are saying passing the same structure to GetTime() twice in a row will yield an error? What error? Why would the GetTime() implementation read the structure at all?

Anyway, if you happen to run across an UEFI firmware implementation that fails in GetTime() unless the output structure is cleared to all zero, I think this is a crucial thing to document. The spec seems to be clear that all-zero Time is invalid, so I am fine with merging this as it is.

[Ayush1325]

Sorry, my bad. Using MaybeUninit::uninit() works. It's just that the NULL pointer does not work.

Of course, I am only testing on qemu with OVMF currently.

[dvdhrm]

Sorry, my bad. Using MaybeUninit::uninit() works. It's just that the NULL pointer does not work.

No worries! I am just glad this is not a weird implementation quirk.

Of course, I am only testing on qemu with OVMF currently.

We all are :) But sooner or later people will report the weirdest behavior of their firmware...

I will merge this nonetheless, as I think it is quite useful if you want to avoid the MaybeUninit dance. Thanks, and sorry for the long discussion!