Page MenuHomePhabricator

Document Clang's expectations of the C standard library.
Needs ReviewPublic

Authored by rsmith on Sep 1 2020, 5:10 PM.

Details

Reviewers
fhahn
rjmccall
Summary

Diff Detail

Event Timeline

rsmith created this revision.Sep 1 2020, 5:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2020, 5:10 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
rsmith requested review of this revision.Sep 1 2020, 5:10 PM
rsmith updated this revision to Diff 289329.Sep 1 2020, 5:12 PM

Add missing word.

Wording looks good. Should we alsso document our assumptions about what functions exist in the standard library — the functions that we'll always use even in freestanding builds?

Wording looks good. Should we alsso document our assumptions about what functions exist in the standard library — the functions that we'll always use even in freestanding builds?

Sounds like a good idea to me. Do we have a list?

@t.p.northover says it's complicated. memcpy, memmove, memset, and bzero are (I think) the only ones that LLVM will potentially synthesize from nothing and therefore need to be present even in freestanding builds; that's probably okay for us to guarantee. That's probably also a good place to document the supported way to write those functions in libraries (just -fno-builtin, IIRC?).

In hosted builds, we should document that we assume the existence of the standard C library for the target platform, potentially including non-standard functions like exp10.

aaron.ballman added inline comments.
clang/docs/Toolchain.rst
289

While I think it's good that we're documenting this, it is really troubling that Clang community's perspective is "we can't work with a conforming C standard library" without filing any DRs to WG14 about why we cannot conform, especially if other major compilers are in a similar boat. Do you have any interest in filing a DR to see if we can change the C standard?