I opened a support ticket with Apple and ask them if it's legit, but no reply so far. In my experience, Apple Support cannot recognise whether their own emails are legitimate or not. And their "report phishing" email address does not reply. Most likely, it is legitimate if the reply address was @ apple.com (and not app1e.com etc. etc.). It's unlikely that a phisher would be able to intercept your reply to an @ apple.com address. Maybe post the email headers here and someone who knows a bit about email forensics will be able to advise.

I think a missing return statement is at most a warning, not an error, in C-family languages. (A quick test with gcc gives an error with -Wall, but nothing with -W.)

Is there any way to check in App Store Connect that Apple has sent us the payments for the previous months? I would expect to see "Paid" at the top right of the Payments and Financial Reports app store connect screen for those months only if the payment has actually been sent. For example, for July I see: September 1, 2022 Transaction ID: 1234567890 Paid I would expect it to say "carried forward" or something if the payment was not sent.

There is no way to synchronise your tier change with the price changes, so inevitably there will be a period of time when either the price is too low or too high. You need to decide whether too high or too low is preferable. Note that in the past Apple have not sent out emails when the price change actually happens, so you need to watch carefully. I have previously submitted a feature request asking for a way to synchronise a tier change with an announced price change, with no feedback from Apple. You might like to do that too. In general, it’s likely that the new prices won’t have the same price available as you were using before. You might get lucky though.

I'm bored with this now. Constant streams of spam, surely easily filterable, yet nothing is done. Apple, don't you find this embarrassing? There is lots about this forum for you to be embarrassed about - the number of non-developer posts, the overwhelming proportion of questions that are not answered, the small number of knowledgable people posting useful replies, and so on. Many of those are things that you can't do much about, but surely solving the spam problem is within the capabilities of a multi-billion-dollar corporation.

Same Issue Same answer. Are you using the Homebrew g++, or the Xcode g++ which is actually clang?

I am compiling code using gnu compiler instead of clang compiler. It would have been useful to know that earlier. I think your best option is to ask the Homebrew people for advice. As noted above, I have a lot of homebrew packages installed but not compilers.

but I am getting the same error how do I rectify that? thanks! Start by using the Xcode g++ (which is actually clang), not the homebrew g++. I'm not sure what the best way to do that is; I do have a lot of homebrew packages installed but not any compilers. If you want to have both homebrew and xcode compilers installed it may be sufficient to adjust your PATH - or it may not. I bet this is a Homebrew FAQ. Or, if you want to get the homebrew compiler working, try asking the homebrew people at e.g. https://github.com/Homebrew/discussions/discussions Curious to know if @fanick is using the Homebrew g++, deliberately or not?

@aarnav, that's the homebrew g++, not the Xcode g++ which is actually clang.

Please compile the newer version of code anywhere other than Xcode. MacOS version does not matter. XCode version should be 14.0.0. That's what I did; I copied&pasted the code in your reply "here is the simplified version of the code" above into a file, and compiled on the command line with the g++ invocation exactly as you indicated in an earlier comment. It compiles without error. Note again that I'm using macOS 12.5 on ARM. My guess is that there is something odd in your environment. For example, since you're the sort of person who is happy to #define int :-) , do you have any shell aliases set up? Is g++ actually an alias for something else? Suggestion for how to debug this: run g++ --verbose and compare with what I get: % g++ --verbose --std=c++17 -W -Wall solution.cpp Apple clang version 14.0.0 (clang-1400.0.29.102) Target: arm64-apple-darwin21.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple arm64-apple-macosx12.0.0 -Wundef-prefix=TARGET_OS_ -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -emit-obj -mrelax-all --mrelax-relocations -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name solution.cpp -mrelocation-model pic -pic-level 2 -mframe-pointer=non-leaf -fno-strict-return -fno-rounding-math -funwind-tables=2 -fobjc-msgsend-selector-stubs -target-sdk-version=12.3 -fvisibility-inlines-hidden-static-local-var -target-cpu apple-m1 -target-feature +v8.5a -target-feature +fp-armv8 -target-feature +neon -target-feature +crc -target-feature +crypto -target-feature +dotprod -target-feature +fp16fml -target-feature +ras -target-feature +lse -target-feature +rdm -target-feature +rcpc -target-feature +zcm -target-feature +zcz -target-feature +fullfp16 -target-feature +sm4 -target-feature +sha3 -target-feature +sha2 -target-feature +aes -target-abi darwinpcs -fallow-half-arguments-and-returns -debugger-tuning=lldb -target-linker-version 819.6 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I/usr/local/include -stdlib=libc++ -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1 -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include -internal-externc-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include -internal-externc-isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -W -Wall -Wno-reorder-init-list -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-final-dtor-non-final-class -Wno-extra-semi-stmt -Wno-misleading-indentation -Wno-quoted-include-in-framework-header -Wno-implicit-fallthrough -Wno-enum-enum-conversion -Wno-enum-float-conversion -Wno-elaborated-enum-base -Wno-reserved-identifier -Wno-gnu-folding-constant -Wno-cast-function-type -Wno-bitwise-instead-of-logical --std=c++17 -fdeprecated-macro -fdebug-compilation-dir=/Users/phil/test_crap -ferror-limit 19 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fno-cxx-modules -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcommon -fcolor-diagnostics -clang-vendor-feature=+messageToSelfInClassMethodIdReturnType -clang-vendor-feature=+disableInferNewAvailabilityFromInit -clang-vendor-feature=+disableNonDependentMemberExprInCurrentInstantiation -fno-odr-hash-protocols -clang-vendor-feature=+enableAggressiveVLAFolding -clang-vendor-feature=+revert09abecef7bbf -clang-vendor-feature=+thisNoAlignAttr -clang-vendor-feature=+thisNoNullAttr -mllvm -disable-aligned-alloc-awareness=1 -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/n4/lyzh1r8n1wl77pqsjpm6xm440000gn/T/solution-945b01.o -x c++ solution.cpp clang -cc1 version 14.0.0 (clang-1400.0.29.102) default target arm64-apple-darwin21.6.0 ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /usr/local/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory) End of search list. "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -no_deduplicate -dynamic -arch arm64 -platform_version macos 12.0.0 12.3 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o a.out -L/usr/local/lib /var/folders/n4/lyzh1r8n1wl77pqsjpm6xm440000gn/T/solution-945b01.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/lib/darwin/libclang_rt.osx.a I think the error is maybe actually coming from the linker. g++ --verbose doesn't pass --verbose to the linker, but I know there is some magic invocation that will do that. See if you can find it.

Here is the simplified version of above code with the same issue:- Works for me on macOS 12.5, ARM, Xcode 14.0.0. Sorry, I'm not going to install the 12.6 beta just to check this!!! Remind me when it is released and I'll try again. Those two lines have nothing to do with this issue as I have been using them since years. Indeed they are probably nothing to do with the issue, but they're still very unconventional and you should not use them. The fact that something has been working for years doesn't mean that it's right, by any means! I would also suggest that you turn on warnings (-W and possibly -Wall). They don't report anything in this case, but it's still good practice.

Turn off bitcode? (Bitcode is deprecated.)

it will be all fine? Definite Maybe.

I think the more important part of their email is the one that I quoted, saying "Non-US residents and non-US legal entities are not required to provide a US tax ID." That conflicts with my experience, which was a few years ago. I don't have anything to add to what I said earlier. I got a US Tax ID for my business, which was not difficult, and used it to complete the form. Apple now tell you that that is not necessary. Either what I did was unnecessary, or they are wrong, or something has changed. I don't know which. You might consider following their advice and find yourself a local tax advisor with suitable experience who can tell you what to do.

#include<bits/stdc++.h> #define int long long int Those two lines are ..... unconventional??! Does it still fail if you instead #include specific headers for vector, iostreams etc. and use a non-reserved-word (e.g. "Int") for your long long int macro? How exactly are you compiling it? Edited to add: After you've changed your #define to Int not int, change the signature of main back to int main.