Thanks for the heads up! My only general comment is that unless this change has no externally observable effect I'd suggest adding tests. (Otherwise, noting it has no such effect would be helpful.) When I'm not familiar with the code (and often even what I am) I usually look for tests to understand the impact of a change.

Changes from previous version:

• Replace loop with Expr::IgnoreImpCasts().
• Use a multiline comment in a test to improve readability.

Changes in revision 3 of the patch addressing review comments:

• Add missing return statement.
• Remove test for argument bit width >= 16.
• Use isa instead of dyn_cast.

Ping: @efriedma do you (or anyone else) have any other questions or suggestions or is everyone okay with the last revision?

Update to the latest diff that didn't get picked up in the first submission.

Restore early return when GetStringLength returns zero.

In D130666#3760810, @joanahalili wrote:

This might break the following opensource lib https://git.kernel.org/pub/scm/network/iproute2/iproute2.git

In https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/configure#n445

The compilation for the following code no longer fails when setting -Wno-error-implicit-function-declaration

#include <string.h>
int main(int argc, char **argv) {
	char dst[10];
	strlcpy(dst, "test", sizeof(dst));
	return 0;
}

The behaviour difference between clang 14.0, clang trunk and gcc: https://godbolt.org/z/hKETMoEd6

The point here is that these loads are going to be expanded into 16 byte-sized loads by the backend, if the target has strict alignment. See https://llvm.godbolt.org/z/MdqoEEv1P for an example.

In D132960#3759601, @efriedma wrote:

To be clear, this is proposing to replace a memcmp of 8 bytes with up to 16 byte-sized loads on targets with strict alignment? That seems excessive to me.

Ping: Are there any comments on the substance of this change?

Ping: Is someone available to review this?

Revision 2 with the following changes:

• Enhance the signature validation to cover known forms for all supported targets.
• Likewise, enhance the folder code to handle all known forms of the function signatures.
• Add tests.
• Adjust TargetLibraryInfoTest.cpp to cover the functions.

In D130666#3727473, @thakis wrote:

This doesn't build on Mac: http://45.33.8.238/macm1/42588/step_4.txt

Revision 1 of the patch with the following changes:

• Annotate source argument dereferenceable regardless of the bound.
• Use getConstantStringInfo instead of GetStringLength to detect unterminated arrays.
• Add tests.

Changes in revision 1 of the patch include:

• Avoid annotating destination argument when bound is not known to be nonzero.
• Correct stpncpy return value to strnlen(S, N) rather than strlen(S).
• Simplify common logic .
• Add tests.

Patch committed in rG0dcfe7aa35cd.

Thanks for the confirmation! I've CC'd @efriedma who has reviewed changes in this in this area before. If there are no other comments I'll plan on installing the patch later this week to resolve the ffs abort.

Ping: Does anyone have any comments on this enhancement?

Ping: @efriedma, do you (or anyone else) have any other questions/comments or is everyone happy with the last revision?

Revision 4 of the patch addressing style nits.

In D129224#3690668, @alexfh wrote:

Thanks for the test case! The bug is in skipping over the leading part of the string up to the first digit and not accounting for it in the end pointer. It should be straightforward to fix. I'll take care of it today.

I like the idea of defining the signatures using the TLI_ macros in TargetLibraryInfo.def. It keeps most of the related bits together in the same place.

I think I just equated the 32-bit StringRef limit with INT_MAX. Thanks for pointing that out!

Revision 2 of the patch modifies TargetLibraryInfoImpl::isValidProtoForLibFunc to use the same consistent approach to validate the vast majority of known library functions. It replaces the repetitive (verbose and error-prone) argument checking used for groups of functions with a single "table-driven" algorithm. For better organization it also rearranges the functions by the header they're declared in. (A further improvement here, to avoid duplication, might be also to arrange them within each header by their number of arguments.) Finally, this revision is parameterized on the result of getIntSize() to correctly validate int arguments in 16-bit environments rather than assuming the type is 32 bits everywhere.

Ping: @efriedma, please let me know if you have any further comments or suggestions, or if the last revisions is good enough to commit. Thanks!

Thanks for the comments. I actually wasn't quite sure the patch was ready for review because there are more functions where the checking should be tightened up. But since you've already gone through it let me ask a few questions:

1. Should I submit one patch with all of them or two or more smaller patches?
2. The functions are not in any particular order, which tends to lead to repetitive checks in different places, and is also more error-prone. I've already moved some of them together (grouped by the header they're declared in) but I wonder: should I do it for all of them? (I.e., have groups by header with no repetitive checks in each group.)
3. The argument checking is also exceedingly verbose with the differences often being just the argument number or type. These differences would be easier to see (and harder to miss when adding new checks) if we cut down on the amount of superfluous text (e.g., avoided calling getParamType(N) for each argument and instead provided an accessor, like operator[]). Would you support this change?

Revision 5 with an expanded comment explaining why sequences that end parsing prior to the terminating nul are not accepted.

Revision 4 with the following changes:

• correct base autodetection to consume the 0x prefix also in base 16,
• reject more variants of empty subject sequences including sole "+" and "0x",
• add tests for the above.

I see. It's valid, for example, to declare { i32, i32 } @div(i32, i32) like the test does but that's not necessarily the same as the div declaration that Clang might emit for div_t div(int, int) on some targets. This lets the test pass even on the same target as with an incompatible div and even though the corresponding C test would not (Clang would presumably issue -Wincompatible-library-redeclaration). To catch these problems tests that exercise the C interface to a library would need to be written in C and ideally run for all supported targets.

Thanks for the pointer to D65457!

Revision 3 with one change from previous:

• Use maxUIntN(unsigned) instead of a case/switch statement.

Revision 2 of the patch addressing reviewer suggestions:

• Use a conditional instead of conversion from bool.
• Avoid assuming atoi etc. argument is a nul-terminated string.
• Use llvm::isDigit et al. instead of the C standard functions.
• Use SaturatingMultiplyAdd to detect overflow.
• Update getConstantStringInfo to make it clear it need not return a nul-terminated string.
• Add tests.

Changes in revision 2 of the patch:

• Fix spelling/typos.
• Rebase on top of latest trunk with tests precommitted in rGd8b22243c8e9.