Some embedded platforms don't implement the C/POSIX function signal().
For such platforms, it would make sense to detect the absence of this
function and mark tests that rely on it as unsupported.
Details
- Reviewers
ldionne Mordante michaelplatings - Group Reviewers
Restricted Project
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I feel uneasy about this. Different C libraries can choose to skip implementing arbitrary parts of the standard but we should think carefully before adding complexity to libc++ to compensate. From eyeballing the picolibc sources it does support signal(), so perhaps the right answer here is to get other embedded C libs to do likewise?
I'm also not too convinced of this change. One of the issues we have no CI which tests this configuration so we can't test there are no regressions. I also wonder how much support we want to provide for non-conforming C libraries.
Do you have concrete examples of c libraries not implementing this feature and do you know why it's not there?
I am sad to have missed this! This is actually something we run into internally on some configurations as well, and having this would simplify our lives. As with any such configuration, it's always hard to determine whether it's worth upstreaming or keeping downstream, however I wouldn't be surprised if that were a fairly common one. To do things consistently, however, we'd need to also add a buildbot that runs without signals and hence probably introduce a LIBCXX_HAS_NO_SIGNALS setting similar to LIBCXX_HAS_NO_LOCALIZATION and friends. I'm not sure that pulls its weight, but I'd be happy to review something like that to evaluate it.