================ @@ -0,0 +1,50 @@ +// RUN: %clang_cc1 -std=c23 -fsyntax-only -verify %s + +typedef __INT32_TYPE__ int32_t; +typedef __UINT32_TYPE__ uint32_t; ---------------- AaronBallman wrote:
Hmmm, we do not ever predefine that macro within Clang. In fact, I cannot find evidence of any code anywhere which defines that macro, same for `__INT48_TYPE__`, and `__INT40_TYPE__`. I did see evidence of someone doing the wrong thing for `__INT24_TYPE__` though: https://github.com/f1nalspace/final_game_tech/blob/3b5c2c02e98480ae278f7e45627fdc8b60a4d08f/demos/additions/final_audioconversion.h#L17 So I did a bit of digging to see how we got these and was not surprised to see it's ancient, untested code: https://github.com/llvm/llvm-project/commit/55c9877b664c1bc6614ad588f376ef41fe6ab4ca#diff-354d01b108ecba542b9ccce083a74c9ea0714ad00fd08367ad5f8347045024df I would say there's no need to add coverage as part of this PR. In fact, I think we should consider removing these esoteric types from stdint.h; LLVM does not support non-8-bit `char` currently and these definitions should only be introduced in freestanding mode or in very rare circumstances a hosted mode where there's not a stdint.h on the platform. But that's a separate RFC and changes from this PR. https://github.com/llvm/llvm-project/pull/199991 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
