Hi, all.

I know this is not standard C, but I see the word cdecl used as a type
qualifier (?) in external declarations - including the standard
headers - and I'd like to know what it means (and how they it's used).
It is, as far as I know, an extension to std C by several compilers.
(Some use __cdecl instead, which is allowed by the standard.)

This may be off-topic on clc because it's not standard, but I believe
an extension that is common to many compilers isn't so far off the
mark. I apologize if I'm wrong on that point.

-- Marty Amandil (not quite ready to face the firing squad)

In article <dc9961c7-c740-4f15-88a8-206ef195648b@8g2000hse.googlegroups.com>,
Amandil <mazwolfe@gmail.com> wrote:
>Hi, all.
>
>I know this is not standard C, but I see the word cdecl used as a type
>qualifier (?) in external declarations - including the standard
>headers - and I'd like to know what it means (and how they it's used).
>It is, as far as I know, an extension to std C by several compilers.
>(Some use __cdecl instead, which is allowed by the standard.)
>
>This may be off-topic on clc because it's not standard, but I believe
>an extension that is common to many compilers isn't so far off the
>mark. I apologize if I'm wrong on that point.
>
>-- Marty Amandil (not quite ready to face the firing squad)

As far as the dorks in this NG are concerned the use of the "cdecl"
"qualifier" is no more (and no less) relevant to the price of hay in
Kansas than is the use of the "ThroatWarbler Mangrove" "qualifier".

Amandil wrote:
> Hi, all.
>
> I know this is not standard C, but I see the word cdecl used as a type
> qualifier (?) in external declarations - including the standard
> headers - and I'd like to know what it means (and how they it's used).
> It is, as far as I know, an extension to std C by several compilers.
> (Some use __cdecl instead, which is allowed by the standard.)

When I want to know such things I use Google. Did you try that?

http://en.wikipedia.org/wiki/X86_cal...ventions#cdecl probably
tells you what you want to know.

> This may be off-topic on clc because it's not standard, but I believe
> an extension that is common to many compilers isn't so far off the
> mark. I apologize if I'm wrong on that point.

From my brief examination of the webpage cited above, I get the
impression that it's a) platform-specific and b) not restricted to
C implementations. I'd say it's pretty off-topic. The firing squad
are loading their weapons, it's probably time for a final cigar...

Amandil wrote:

> Hi, all.
>
> I know this is not standard C, but I see the word cdecl used as a type
> qualifier (?) in external declarations - including the standard
> headers - and I'd like to know what it means (and how they it's used).
> It is, as far as I know, an extension to std C by several compilers.
> (Some use __cdecl instead, which is allowed by the standard.)
>
> This may be off-topic on clc because it's not standard, but I believe
> an extension that is common to many compilers isn't so far off the
> mark. I apologize if I'm wrong on that point.

It's a compiler attribute to specify the C calling convention for that
function. A calling convention specifies the machine level interface of
that function, i.e, where the function expects it's arguments, where it
returns it's return value, whether it pops of it's arguments or whether
the caller must do that and other such details.

The C calling convention specifies that a function's arguments must be
pushed on to the stack in reverse order of their position in the
function's definition or prototype. It also states that the function's
caller is responsible for balancing the stack after the function call.
The return value would of course be in different places depending on
the architecture, but for the x86 they are in registers EAX or EDX:EAX
depending on their size. Larger structures may have to be returned on
the stack.

Note that the "C" calling convention has not been codified by the
standard, but is more of a de facto standard among compilers and
systems that has become ubiquitous due to widespread usage.

There are many other calling conventions. Some other popular ones
are "stdcall", and "fastcall".

A Google search will give you far more (and far better) details on all
of these subjects.

On Mar 4, 11:58 am, Mark Bluemel <mark_blue...@pobox.com> wrote:
> Amandil wrote:
> > Hi, all.
>
> > I know this is not standard C, but I see the word cdecl used as a type
> > qualifier (?) in external declarations - including the standard
> > headers - and I'd like to know what it means (and how they it's used).
> > It is, as far as I know, an extension to std C by several compilers.
> > (Some use __cdecl instead, which is allowed by the standard.)
>
> When I want to know such things I use Google. Did you try that?
>
> http://en.wikipedia.org/wiki/X86_cal...#cdeclprobably
> tells you what you want to know.

Thanks. Tells me enough, I suppose.

> > This may be off-topic on clc because it's not standard, but I believe
> > an extension that is common to many compilers isn't so far off the
> > mark. I apologize if I'm wrong on that point.
>
> From my brief examination of the webpage cited above, I get the
> impression that it's a) platform-specific and b) not restricted to
> C implementations. I'd say it's pretty off-topic. The firing squad
> are loading their weapons, it's probably time for a final cigar...

I didn't realize it was platform specific. I guess I just don't get
around that much. I did see it both on the MS C compiler and on gcc,
so I assumed it was used more than that.

I don't smoke, but I'm eating my last meal and saying my prayers...
Really, I'm sorry I was OT, I just didn't know where else to go. I am,
after all, still fairly new. Again, apologies and thanks.

-- Marty Amandil (hiding in the bomb shelter...)

On Mar 4, 12:07 pm, santosh <santosh....@gmail.com> wrote:
> Amandil wrote:
> > Hi, all.
>
> > I know this is not standard C, but I see the word cdecl used as a type
> > qualifier (?) in external declarations - including the standard
> > headers - and I'd like to know what it means (and how they it's used).
> > It is, as far as I know, an extension to std C by several compilers.
> > (Some use __cdecl instead, which is allowed by the standard.)
>
> > This may be off-topic on clc because it's not standard, but I believe
> > an extension that is common to many compilers isn't so far off the
> > mark. I apologize if I'm wrong on that point.
>
> It's a compiler attribute to specify the C calling convention for that
> function. A calling convention specifies the machine level interface of
> that function, i.e, where the function expects it's arguments, where it
> returns it's return value, whether it pops of it's arguments or whether
> the caller must do that and other such details.
>
<etc. Snipped for brevity. I hate long quotes>

Thanks. I basically know about the C calling convention, so I
understand your answer well enough. I hadn't known about cdecl being
related to those, though.

-- Marty

In article <fqjv30$eii$1@aioe.org>,
Mark Bluemel <mark_bluemel@pobox.com> wrote:
>Amandil wrote:
>> Hi, all.
>>
>> I know this is not standard C, but I see the word cdecl used as a type
>> qualifier (?) in external declarations - including the standard
>> headers - and I'd like to know what it means (and how they it's used).
>> It is, as far as I know, an extension to std C by several compilers.
>> (Some use __cdecl instead, which is allowed by the standard.)
>
>When I want to know such things I use Google. Did you try that?
>
>http://en.wikipedia.org/wiki/X86_cal...ventions#cdecl probably
>tells you what you want to know.

Note that, according to the dogma of clc, Wikipedia is a) the work of
the devil and b) completely unreliable. If you don't believe me, feel
free to use Google Groups and you'll see.

So, one certainly can't use Wikipedia as a suggested reference resource
and still expect to keep one's Clique membership in good standing.

Furthermore, and I'm now speaking entirely seriously, without
tongue-in-cheek, maybe the OP would actually *like* to hear your
opinions. Maybe he actually would prefer the commentary of real, live,
honest-to-goodness humans, instead of sterile cold reference material.

Ever think of that?

P.S. Of course, once he's spent some time in CLC, he'll realize that
there aren't any real, live, honest-to-goodness humans here, but that
doesn't mean he can't come in with honest expectations.

santosh wrote:
> [...]
> The C calling convention specifies that a function's arguments must be
> pushed on to the stack in reverse order of their position in the
> function's definition or prototype. It also states that the function's
> caller is responsible for balancing the stack after the function call.
> The return value would of course be in different places depending on
> the architecture, but for the x86 they are in registers EAX or EDX:EAX
> depending on their size. Larger structures may have to be returned on
> the stack.
>
> Note that the "C" calling convention has not been codified by the
> standard, but is more of a de facto standard among compilers and
> systems that has become ubiquitous due to widespread usage.
> [...]

"Ubiquitous" means "existing or being everywhere, esp. at
the same time; omnipresent." Since there are plenty of machines
around that use non-stack storage for at least some arguments,
and that assign the responsibility for stack management (if
any) differently, "common" might be a better choice of word.

"Common" means "hackneyed; trite, of mediocre or inferior
quality; mean; low, coarse; vulgar, lacking rank, station,
distinction, etc.; unexceptional; ordinary."

--
Eric.Sosman@sun.com

In article <1204653046.197140@news1nwk>,
Eric Sosman <Eric.Sosman@sun.com> wrote:
>santosh wrote:
>> [...]
>> The C calling convention specifies that a function's arguments must be
>> pushed on to the stack in reverse order of their position in the
>> function's definition or prototype. It also states that the function's
>> caller is responsible for balancing the stack after the function call.
>> The return value would of course be in different places depending on
>> the architecture, but for the x86 they are in registers EAX or EDX:EAX
>> depending on their size. Larger structures may have to be returned on
>> the stack.
>>
>> Note that the "C" calling convention has not been codified by the
>> standard, but is more of a de facto standard among compilers and
>> systems that has become ubiquitous due to widespread usage.
>> [...]
>
> "Ubiquitous" means "existing or being everywhere, esp. at
>the same time; omnipresent." Since there are plenty of machines
>around that use non-stack storage for at least some arguments,
>and that assign the responsibility for stack management (if
>any) differently, "common" might be a better choice of word.
>
> "Common" means "hackneyed; trite, of mediocre or inferior
>quality; mean; low, coarse; vulgar, lacking rank, station,
>distinction, etc.; unexceptional; ordinary."
>
>--
>Eric.Sosman@sun.com

Eric is a "Tireless Rebutter". Comments?

gazelle@xmission.xmission.com (Kenny McCormack) writes:

> In article <1204653046.197140@news1nwk>,
> Eric Sosman <Eric.Sosman@sun.com> wrote:
>>santosh wrote:
>>> [...]
>>> The C calling convention specifies that a function's arguments must be
>>> pushed on to the stack in reverse order of their position in the
>>> function's definition or prototype. It also states that the function's
>>> caller is responsible for balancing the stack after the function call.
>>> The return value would of course be in different places depending on
>>> the architecture, but for the x86 they are in registers EAX or EDX:EAX
>>> depending on their size. Larger structures may have to be returned on
>>> the stack.
>>>
>>> Note that the "C" calling convention has not been codified by the
>>> standard, but is more of a de facto standard among compilers and
>>> systems that has become ubiquitous due to widespread usage.
>>> [...]
>>
>> "Ubiquitous" means "existing or being everywhere, esp. at
>>the same time; omnipresent." Since there are plenty of machines
>>around that use non-stack storage for at least some arguments,
>>and that assign the responsibility for stack management (if
>>any) differently, "common" might be a better choice of word.
>>
>> "Common" means "hackneyed; trite, of mediocre or inferior
>>quality; mean; low, coarse; vulgar, lacking rank, station,
>>distinction, etc.; unexceptional; ordinary."
>>
>>--
>>Eric.Sosman@sun.com
>
> Eric is a "Tireless Rebutter". Comments?

I can only comment that he has the usage of "common" almost entirely wrong in
this context. And is being, as a result, somewhat misleading.

'It is very "common" to find' doesn't mean anything to do with low
quality, trite etc whatsoever. Why he should do this I'm not sure. Yes
"ordinary" would be ok, but why include all the negative connotations
too?

"Eric Sosman" writes:

> santosh wrote:

>> Note that the "C" calling convention has not been codified by the
>> standard, but is more of a de facto standard among compilers and
>> systems that has become ubiquitous due to widespread usage.
>
> "Ubiquitous" means "existing or being everywhere, esp. at
> the same time; omnipresent." Since there are plenty of machines
> around that use non-stack storage for at least some arguments,
> and that assign the responsibility for stack management (if
> any) differently, "common" might be a better choice of word.
>
> "Common" means "hackneyed; trite, of mediocre or inferior
> quality; mean; low, coarse; vulgar, lacking rank, station,
> distinction, etc.; unexceptional; ordinary."

This discussion belongs in alt.usage.english.

But since you brought it up, I would say that any dictionary that listed
hackneyed as first and ordinary as last in a definition of common is
certainly an inferior dictionary. The dictionary sounds like it is cdecl
friendly, i.e., backwards.

I was all set to say that "__cdecl" and "__stdcall" were C and C++
keywords, because they always turn blue in every IDE I've used.

But, on looking for them in the standards, I see that just aint so!

On doing some googling, it seems these are mostly (or perhaps solely)
Microsoft Windows features. They appear not to be used in any other
operating system. Try asking about them in the following groups:

comp.os.ms-windows.programmer.win32
microsoft.public.win32.programmer

But in a nutshell, these two declarators specify how the stack is
used when a function is called. For "__cdecl", the calling function
does the stack clean-up; for "__stdcall", the called function does
the stack clean-up. Also, "__stdcall" doesn't handle functions with
variable number of arguments. In practice, "__stdcall" is used for
all API callback functions, and "__cdecl" is used for everything
else.

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant