Just post an example what you want to accomplish. Type promotion rules applies here without an issue.
As said, literals are per definition signed. Even if you change the $FFFFFFFF etc to unsigned, then still the 0 is signed.
Problem in FPC, however, is arbitrary rule for unwanted integer literals implicit conversion, as already pointed.
Anything relating to the highest unsigned type is arbitrary, as I have explained it to be a hack since there is no larger signed type for it. But solutions must be limited to the place where the literal is parsed, and not fan out to every place where a literal might be used to try to preserve the expression as unsigned.
That is not fixing a corner case, but changing the language so far that it might as well be a new one.
And that brings us back to how Delphi does it. All this talk about C/C++ is utterly useless.
p.s. As I said before: if you want to make a standards argument, you must base it purely on the text. Testing with a compiler clouds the issue with potentially implementation defined behaviour.
All papers for C++ standards are here
https://isocpp.orgFor instance, C++20 standard is here:
https://isocpp.org/files/papers/N4860.pdfGNU C/C++ have to follow all these rules for specific standard, before they claims it is fully supported, is it?
[/quote]
They are like minimal rules. But not all behaviour that you see might be required, that 's what "implementation defined" means (and IIRC that is a term from K&R). See e.g.
https://en.wikipedia.org/wiki/Unspecified_behaviorIOW two different C compilers might react different, but still be standards compliant. Therefore you can't advocate as anything GCC does as "the will of the standard". It might be one choice of many in the optional parts of the standard.