yuleisui
commented
1 year ago Thanks for pointing them out. Your findings all make sense to me. Please go ahead with pull request. @shuangxiangkan could you please also check the above issues for external APIs?
Debugging an unsound points-to set led me on a wild goose chase of ExtAPI functions that do not seem to be modeled entirely according to the semantics of the man pages.
Unsoundly modeled dynamic allocations
asprintfandvasprintfallocate memory (should be freed later by the caller) and stores a pointer to it in the first argument (output argument). SVF's current extapi.json treats this function as EFT_NOOP however. Should these not be an EFT_A0R_NEW? -> PR: #1084realpathcan allocate memory for its return value, but ExtAPI currently only models a copy edge between its arguments, not the return value being a (possibly) newly allocated object (it depends on the arguments being non-null).getaddrinfoallocates a linked list of structures and returns it via output argument. It's quite unique: the allocated object is initialized and can refer to other, new allocations. I don't think there's a good way to model this with the current ExtAPI grammar.Pointers to static buffers modeled as EFT_NOSTRUCT_ALLOC
Many functions in the ExtAPI that are modeled as EFT_NOSTRUCT_ALLOC return a pointer to a statically allocated buffer instead. The return values of multiple calls to these functions should alias, but, if my understanding is right, they currently don't. If I understand correctly, EFT_STAT would be more appropriate? Examples include:
getenv,getlogin,getpass. These are all specified by the man pages to return a pointer into a static buffer, so it's not an implementation detail. For thestrerrorandstrsignalfamily of functions, this is not (exactly) specified by the man pages, but it's implied and most sane implementations do so.In fact, most of the EFT_NOSTRUCT_ALLOC functions in the extapi seem to actually be EFT_STATs?
Missing ExtAPI entries
pmtraceerrstris also one of these error-handling string functions, but not modeled by ExtAPI right nowopen_memstream/open_wmemstreamare absent, but they allocate dynamic memorywcsdupis similar tostrdup, but not modeledMethodology
There's more than the ones I listed here. I obtained some by just stumbling on them, but others by systematically scanning the man pages for tell-tale terminology. Most man pages of functions that dynamically allocate memory mention that the returned pointer can be "passed to free". Most man pages of functions that deal with statically allocated buffers mention "statically allocated" or "static buffer". I've found these queries to produce pretty precise results, with little noise.
Happy to supply pull requests for these if need be, just wanted to check if my understanding of the "new" ExtAPI is correct and whether it's desirable to update the handling of these functions.