std.elf: stronger typing #23600
std.elf: stronger typing #23600
Conversation
|
yes i know i still have to update references elsewhere in the codebase :) 2 questions i have:
|
|
also note that i didn't convert all groups of values to enums/bitfields - for example, |
dotcarmen
force-pushed
the
elf-stronger-typing
branch
4 times, most recently
from
3f37b69 to
4bf9545
Compare
dotcarmen
force-pushed
the
elf-stronger-typing
branch
from
4bf9545 to
170ac8d
Compare
dotcarmen
force-pushed
the
elf-stronger-typing
branch
from
170ac8d to
63745ce
Compare
| pub fn sectionHeaders( | ||
| self: *const Header, | ||
| parse_source: anytype, | ||
| ) SectionHeaders(@TypeOf(parse_source)) { | ||
| return .new(self, parse_source); | ||
| } |
There was a problem hiding this comment.
header.section_header_iterator(file) -> header.sectionHeaders(file).iterator()
| strtab_header: *const elf64.Shdr, | ||
| parse_source: anytype, | ||
| ) StringTable(@TypeOf(parse_source)) { | ||
| _ = self; |
There was a problem hiding this comment.
feels right to still have this be a method on Header, even though there's no use for self in this method... if it's preferred to add method Shdr.asStringTable instead then i can do that.
| 8 => Elf64_Relr, | ||
| else => @compileError("expected pointer size of 32 or 64"), | ||
|
|
||
| pub const SHF_OSBITS = packed struct(u8) { |
There was a problem hiding this comment.
the SHF os/proc bitflag types are the most awkward api changes. feedback on a better pattern would be appreciated
There was a problem hiding this comment.
lately i've been focusing on iterating the API re: my os project so i haven't been working on updating the API usage around the codebase. i'm getting to that soon :)
supercedes #23178
This PR attempts to make
std.elfa bit easier for API consumers:ELF32_*andELF64_*types have been moved/renamed intoelf32andelf64namespacespub const x = switch (@sizeOf(usize)) { ... };declarations have been consolidated into a singlepub const native_elfwhich selects eitherelf32orelf64note: to optimize the reviewer's experience, i'll keep this PR as 2 commits: the first commit will be the API changes to
std.elf, and the 2nd commit will be downstream changes