Re: Calling conventions (particularly 32-bit ARM)

On 10/01/2025 19:39, Scott Lurndal wrote:

David Brown <david.brown@hesbynett.no> writes:

On 09/01/2025 08:23, Anton Ertl wrote:

Stefan Monnier <monnier@iro.umontreal.ca> writes:
[Someone wrote:]

ABI calling conventions tend to be designed to support at least C,
including varargs and often also tolerant of differences between the
number of arguments in the caller and callee.

>
Why should an ABI be tolerant of such differences?  In C, calling a
function with an unexpected number (or type) of arguments has always
been undefined behaviour, and always been something that programmers
have strived to avoid.  For variadic functions (including old
pre-standard functions), the code does not declare the number or types
of arguments, but you still have to match up the caller and callee.

 I'm not sure that's completely true.   Consider, for example,
main().  It's sort of variadic, but most applications only declare
the standard C argc/argv arguments.  POSIX systems supply
a third parameter (envp) and most unix/linux implementations
supply a fourth parameter (auxv).
 I should think so long as the caller provides at least enough
parameters to match the callee, there shouldn't be any
issues.

main() is a special case in C and C++ - it seems fine to say that it takes a particular implementation-defined set of parameters no matter how it is declared.  If it is defined with fewer parameters than the implementation supports, then the definition should be treated as though those parameters were included but not used.

 

Call printf() with a mismatch between the format string and the
arguments, and you can expect nasal daemons.

 Not if you provide _more_ parameters than the format string
requires, which can happen with e.g. i18n error message strings.
 

I've always thought printf was a very unsafe design concept - that usage does not help!