This is an archive of the discontinued LLVM Phabricator instance.

[Headers] Add missing __need_ macros to stdarg.h
ClosedPublic

Authored by iana on Aug 12 2023, 11:21 AM.

Details

Summary

Apple needs a __need_ macro for va_list. Add one, and also ones for va_start/va_arg/va_end, __va_copy, va_copy.

Diff Detail

Event Timeline

iana created this revision.Aug 12 2023, 11:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 12 2023, 11:21 AM
Herald added a subscriber: ributzka. · View Herald Transcript
iana requested review of this revision.Aug 12 2023, 11:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 12 2023, 11:21 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
iana edited the summary of this revision. (Show Details)Aug 12 2023, 11:21 AM

Apple needs a need_ macro for va_list. Add one, and also ones for va_start/va_arg/va_end, va_copy, va_copy.

Do you have a link to the specification or the source that this is needed?

iana added a comment.EditedAug 13 2023, 9:35 PM

Apple needs a need_ macro for va_list. Add one, and also ones for va_start/va_arg/va_end, va_copy, va_copy.

Do you have a link to the specification or the source that this is needed?

We need this so that our <sys/_types/_va_list.h> doesn't have to redeclare va_list and doesn't pull in all of stdarg.h either. As far as I know there's no specification for this (or stddef.h) being include-able in pieces.

Apple needs a need_ macro for va_list. Add one, and also ones for va_start/va_arg/va_end, va_copy, va_copy.

Do you have a link to the specification or the source that this is needed?

We need is so that our <sys/_types/_va_list.h> doesn't have to redeclare va_list and doesn't pull in all of stdarg.h either. As far as I know there's no specification for this (or stddef.h) being include-able in pieces.

I'm not opposed, but this adds significant complexity to support a questionable use case -- the C standard library headers are not intended to be partially included, so if the plan is to use these __need macros in all of the headers we provide, I think that should go through an RFC process to be sure we want to maintain the added complexity. (Also, who is "we" in this case?)

iana added a comment.Aug 14 2023, 10:11 AM

Apple needs a need_ macro for va_list. Add one, and also ones for va_start/va_arg/va_end, va_copy, va_copy.

Do you have a link to the specification or the source that this is needed?

We need is so that our <sys/_types/_va_list.h> doesn't have to redeclare va_list and doesn't pull in all of stdarg.h either. As far as I know there's no specification for this (or stddef.h) being include-able in pieces.

I'm not opposed, but this adds significant complexity to support a questionable use case -- the C standard library headers are not intended to be partially included, so if the plan is to use these __need macros in all of the headers we provide, I think that should go through an RFC process to be sure we want to maintain the added complexity. (Also, who is "we" in this case?)

We is Apple. We have a <sys/_types/_va_list.h> header that is generating redeclaration warnings in modules mode. I can't just include <stdarg.h> instead since it would change the semantics of <sys/_types/_va_list.h>. stdarg.h and stddef.h appear to be the only clang headers that Apple needs to use in pieces though, I don't think we should add this complexity to any other headers for consistency or "just because".

Apple needs a need_ macro for va_list. Add one, and also ones for va_start/va_arg/va_end, va_copy, va_copy.

Do you have a link to the specification or the source that this is needed?

We need is so that our <sys/_types/_va_list.h> doesn't have to redeclare va_list and doesn't pull in all of stdarg.h either. As far as I know there's no specification for this (or stddef.h) being include-able in pieces.

I'm not opposed, but this adds significant complexity to support a questionable use case -- the C standard library headers are not intended to be partially included, so if the plan is to use these __need macros in all of the headers we provide, I think that should go through an RFC process to be sure we want to maintain the added complexity. (Also, who is "we" in this case?)

We is Apple.

Thank you!

We have a <sys/_types/_va_list.h> header that is generating redeclaration warnings in modules mode. I can't just include <stdarg.h> instead since it would change the semantics of <sys/_types/_va_list.h>. stdarg.h and stddef.h appear to be the only clang headers that Apple needs to use in pieces though, I don't think we should add this complexity to any other headers for consistency or "just because".

Thank you for the explanation; if it's just these two files, I think that's pretty reasonable. I was worried it was also going to spill into limits.h, stdint.h, and other freestanding headers.

clang/test/Headers/stdarg.c
3

I think the triples can be removed.

12

You should spell out the first instance of the diagnostic

35

You should spell out these diagnostics, and I think c99-no-diagnostics should be placed up by the RUN lines so it's more obvious that we expect no diagnostics in C99 mode.

Actually, this file should perhaps be split into two files as they're testing different things. (I was tripped up seeing no-diagnostics but we have c99-error entries above, that's when I realized the split file was being used differently in the RUN lines which is a bit novel.) But I'm not certain I fully understand what your comment means about why we're using split file in the first place, so I might be missing something.

clang/test/Headers/stdargneeds.c
3

Same suggestions in this file regarding triples and spelling out diagnostics, but I think a single file makes sense as this is testing each of the __needs_whatever macros the same way.

iana updated this revision to Diff 550121.Aug 14 2023, 4:13 PM
iana marked 4 inline comments as done.

Review feedback

clang/test/Headers/stdarg.c
35

It's only trying to test what including <stdarg.h> gets you by default. The first chunk is to prove that nothing is provided via built-ins or anything like if you don't include anything. The second chunk shows that you get the expected declarations in each standard mode if you include <stdarg.h> with no __need_ macros.

The problem is this.

va_copy(g, v); // The first time you get: implicitly declaring library function 'va_copy'

va_copy(g, v); // But now the compiler has decided that va_copy has a declaration, so you don't get any diagnostics even though va_copy doesn't have its real declaration, I think the compiler assumes 'int va_copy(int, int)' or something like that.

Maybe we don't need to test the include-nothing case both here and stdargneeds.c?

D157757 has the same problem for offsetof but since it uses C23 also, the diagnostics get repeated.

aaron.ballman accepted this revision.Aug 15 2023, 5:47 AM

LGTM!

clang/test/Headers/stdarg.c
35

Ah, I see now, thank you for the explanation.

The compiler adds an implicit function declaration for va_copy in C (so the signature is int func() as a K&R C function without a prototype), hence the need to split the file.

This seems reasonable to me.

This revision is now accepted and ready to land.Aug 15 2023, 5:47 AM

I'm a bit confused by this change vs its description.

It looks like stdarg already supported __need___va_list, which is what you said Apple needs. Does Apple also require the other __need_va_copy/etc, too? If not, why add support for them? (I think we should prefer not to add support for pieces that are not actually needed)

iana added a comment.Aug 15 2023, 10:17 AM

I'm a bit confused by this change vs its description.

It looks like stdarg already supported __need___va_list, which is what you said Apple needs. Does Apple also require the other __need_va_copy/etc, too? If not, why add support for them? (I think we should prefer not to add support for pieces that are not actually needed)

That name is misleading, __need___va_list gives you __gnuc_va_list and not va_list.

This revision was automatically updated to reflect the committed changes.