Re: calling convention stdcalll and cdecl call

Alf P. Steinbach <alfps@xxxxxxxx> wrote:
* Igor Tandetnik:
printf("%d", 1, 2);

For what it's worth the above example (1) has undefined behavior

Not true. C99 standard explicitly covers this case:

7.19.6.1/2 The fprintf function writes output to the stream pointed to
by stream, under control of the string pointed to by format that
specifies how subsequent arguments are converted for output. If there
are insufficient arguments for the format, the behavior is undefined.
*If the format is exhausted while arguments remain, the excess arguments
are evaluated (as always) but are otherwise ignored.* (emphasis mine).

In 7.19.6.3, printf is defined in terms of fprintf.

I don't have C89 standard handy at the moment, but I'm pretty sure it
contains the same wording.

(2) states that I somehow have ownership of an addressing convention,
which is incorrect and misleading and just idiotic, but typical
weaseling rhetoric

What do you mean by "addressing convention"? I'm not familiar with the
term. Since I don't know what it is, I don't make any statements about
its ownership.

All I state is this. The above call is perfectly valid according to the
standard, so a conforming C compiler has to support it. To execute this
call, three arguments have to be pushed onto the stack, and then later
three arguments have to be popped off. Under cdecl calling convention,
both operations are done by the caller, who of course knows how many
arguments there are.

You seem to suggest that it is perfectly reasonable to require the
callee to clean up the stack instead. I'd like to see what mechanism you
propose to make this possible, other than having the caller pass
additional information to the callee, above and beyond the three
arguments (e.g. the total size of all arguments).

If the mechanism you'd like to propose does involve passing additional
information to the function, then I agree with you in that such a
calling convention would indeed be possible. However, I don't see how it
would be an improvement over cdecl. And since cdecl is already happily
supported by existing tools, it is hard to expect compiler authors to
begin supporting something that is worse. What would be the point?

On the other hand, stdcall is an improvement over cdecl, however minor.
It shifts one machine instruction from the call site (where it has to be
repeated for each call) to the callee (where it exists only once per
function, not once per every place in the program where the function is
called). In exchange for this slight efficiency gain, it loses the
ability to support variadic functions.

and (3) asks a question you already got complete
demonstration code for, and based on that example you yourself
pointed out one possible answer to that question.

Right. My point is _not_ that the technique your sample demonstrates is
impossible. Just that it's unnecessarily complicated and pointless, and
so it's not at all surprising that it's not supported by mainstream
tools.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


.

Relevant Pages

  • compile error on alpha - binutils problem?
    ... {standard input}:246: Error: macro requires $at register while noat in effect ... # PCCARD support ...
    (Linux-Kernel)
  • Re: New Ethiopian Find - Oldest Biped At 3.8-4 mya
    ... >> This is not an example of a double standard. ... > criticise arguments you don't support for not ... *elimination of human hair as it relates to swimming. ... primarily--neither set out to address hair reduction) required a rather ...
    (sci.anthropology.paleo)
  • Re: So, they started synthesizing shared variables?
    ... The standard gives users something to ask your vendor to implement. ... in this case is not VHDL compliant. ... WRT support and not support, the 2004 approach is identical to the ... coding styles that would be accepted by a compliant synthesis tool. ...
    (comp.lang.vhdl)
  • Re: porting from C++Builder
    ... and I do believe that standard support of PME ... the java was growing and, obviously, microsoft initially tried to ...
    (microsoft.public.dotnet.languages.vc)
  • Re: what is cdecl
    ... Amandil wrote: ... I know this is not standard C, but I see the word cdecl used as a type ... qualifier in external declarations - including the standard ...
    (comp.lang.c)