search

9fans / plan9port

Plan 9 from User Space
https://9fans.github.io/plan9port/
Other
1.6k stars 318 forks source link

ramfs starts #635

Closed fgergo closed 6 months ago

fgergo commented 6 months ago

@dancrossnyc with modified erealloc(), ramfs works for me(tm).

Other changes: Maxsize wasn't limiting ramfs memorty usage but per file usage. -u added back from 4e. Man page amended.

4e man page for reference: https://9p.io/magic/man2html/4/ramfs

fgergo commented 6 months ago

@dancrossnyc I really appreciate for taking a look and for your comments! I reverted all changes not relevant to making ramfs work and I meant the new commit message to describe that. ptal

fgergo commented 6 months ago

@dancrossnyc thanks for the merge!

iiuc all plan9 programs can depend on realloc(p, 0), being a free(p). (Ramfs did.) Possibly there are others as well. Meanwhile plan9port programs: % cd $PLAN9/src; u rgrep '^erealloc'|wc 31 124 1418

I'd like to ask your opinion on possibly 1) changing all erealloc(p, 0) functions to mean free(p) and 2) reviewing all other realloc() calls for similar behaviour?

Would you merge 1) if a PR was ready? thanks!

dancrossnyc commented 6 months ago

Yeah, sadly, many C programs in general rely on that behavior; indeed, the 1989 C standard specified that was the behavior. Sadly, the standard change, compiler vendors abused the change, and now here we are where it's UB in C'23. :-( That said, I've talked to the C editor (well, one of the co-editors) about it and I sympathize with the reasons that were outlined to me. They're in sort of an impossibly tight situation.

Anyway, there are a few ways forward. For a wrapper like erealloc, I'd be in favor of changing that function to handle 0 explicitly (as opposed to changing the call sites). For other uses of realloc, it probably makes the most sense to audit them and see what's doing something that may blow up.