__stdcall alternative

[Walter Roberson]

And I showed Eric and you and Thompson that is supported
on gcc/MSVC/Lcc-win/Watcom/Borland and what have you

The searching I did indicated that the __stdcall ABI is used only
on Windows32 (and has some discrepancies between different compilers
and compilation modes even there.) I did not find any Unix type
platforms that support it, though I did find explicit statements
that it is -not- supported on Linux.

With regards to gcc,
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes

The keyword __attribute__ allows you to specify special
attributes when making a declaration. This keyword is followed
by an attribute specification inside double parentheses. The
following attributes are currently defined for functions on all
targets: aligned, alloc_size, noreturn, returns_twice,
noinline, always_inline, flatten, pure, const, nothrow,
sentinel, format, format_arg, no_instrument_function, section,
constructor, destructor, used, unused, deprecated, weak,
malloc, alias, warn_unused_result, nonnull, gnu_inline,
externally_visible, hot, cold, artificial, error and warning.
Several other attributes are defined for functions on
particular target systems.

Notice that stdcall is not amongst the ones defined for all targets.

stdcall
On the Intel 386, the stdcall attribute causes the compiler to
assume that the called function will pop off the stack space
used to pass arguments, unless it takes a variable number of
arguments.

Notice the platform specification in the description.

I would have to dig further to find out what happens if you
use an attribute not supported for a particular platform. My
hypothesis at the moment is that the attribute is ignored.
That would make it legal in gcc to use the stdcall attribute
when compiling on Linux -- it would just have no effect.


And for those of us not using gcc and not compiling on Windows... ?

 

[jacob navia]

That sounds a bit platform-specific! But luckily I do use gcc.


I get:

foo.c:5: warning: 'stdcall' attribute directive ignored

Presumably this is an x86-only declaration.

-- Richard

stdcall means that the called procedure cleans up the stack.
This is needed only when a series of push instructions are
issued when passing arguments. When the machine has a lot of
registers, normally the arguments are passed in registers
and the importance of stdcall is no longer so great.

It saves approx 5% of code space. At each call point, it
is no longer necessary to adjust the stack to compensate
all the push instructions.

 

[jacob navia]

The searching I did indicated that the __stdcall ABI is used only
on Windows32 (and has some discrepancies between different compilers
and compilation modes even there.) I did not find any Unix type
platforms that support it, though I did find explicit statements
that it is -not- supported on Linux.

With regards to gcc,
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes

The keyword __attribute__ allows you to specify special
attributes when making a declaration. This keyword is followed
by an attribute specification inside double parentheses. The
following attributes are currently defined for functions on all
targets: aligned, alloc_size, noreturn, returns_twice,
noinline, always_inline, flatten, pure, const, nothrow,
sentinel, format, format_arg, no_instrument_function, section,
constructor, destructor, used, unused, deprecated, weak,
malloc, alias, warn_unused_result, nonnull, gnu_inline,
externally_visible, hot, cold, artificial, error and warning.
Several other attributes are defined for functions on
particular target systems.

Notice that stdcall is not amongst the ones defined for all targets.

stdcall
On the Intel 386, the stdcall attribute causes the compiler to
assume that the called function will pop off the stack space
used to pass arguments, unless it takes a variable number of
arguments.

Notice the platform specification in the description.

I would have to dig further to find out what happens if you
use an attribute not supported for a particular platform. My
hypothesis at the moment is that the attribute is ignored.
That would make it legal in gcc to use the stdcall attribute
when compiling on Linux -- it would just have no effect.

stdcall means that the called procedure cleans up the stack.
This is needed only when a series of push instructions are
issued when passing arguments. When the machine has a lot of
registers, normally the arguments are passed in registers
and the importance of stdcall is no longer so great.

It saves approx 5% of code space. At each call point, it
is no longer necessary to adjust the stack to compensate
all the push instructions.

> And for those of us not using gcc and not compiling on Windows... ?
>

Well, compile under linux if you wish, buy a MACintosh, run
your programs under Sony play station what do you want?

If you do not have stdcall probably you do not need it.

 

[Ian Collins]

You were attempting to help the original poster by
showing your ignorance.

You're either dense or being obtuse, what's wrong with redirecting a
question somewhere it is topical?

Who cares?

Probably anyone not using windows.

It is supported by gcc and all the platforms gcc runs on,
supported by MSVC, supported by Watcom, Borland, lcc-win,
and what have you.

That is almost 100% of the market. Obviously you use
something else and never look into mainstream computing like
many regulars here.

Ah, the typical myopic rant of a windows programmer. Wake up, most of
the market for C is in the embedded world.

 

[Kenny McCormack]

no, it isn't

"_stdcall" isn't platform-specific? Seriously?
[/QUOTE]

It depends on what you mean by "specific". On Usenet, where everybody
wants to be a standards jockey (not just here [clc], but clc is among the
worst), there is a tendency to use the phrase "platform specific" even
if the thing works on 99% (say) of all platforms. This is not a usage
of the word "specific" that maps to the real world, in any other sphere
of endeavor. One might go on to say that people who use it in this way
are insane.

In the real world, the word "specific" usually implies uniqueness -
i.e., we would say that something is "platform specific" if it worked on
exactly 1 platform (hence, specific to that platform).

 

[Stephen Sprunk]

but you should just issue ret
and the call[ing] procedure adjusts the stack.

(That always seemed a crazy way to do things; one extra instruction /per
call/).

<OT>
The major difference is that the called function doesn't always know how
many bytes were added to the stack before calling, so it doesn't always know
how many to remove when returning. The caller always knows, so it can
always do the work.

Remember, at the time most ABIs were invented, C did not have prototypes and
you were free to pass as many arguments to a function as you desired; if you
passed the wrong number, the calling convention above would keep your
mistake from crashing the system.

Also, it makes implementing variadic functions a _lot_ easier. Many ABIs
use this calling convention for variadic functions even if they use
something "more efficient" (like passing arguments in registers) for normal
functions.
</OT>

S

 

[Flash Gordon]

jacob navia wrote, On 24/04/08 23:32:

Walter Roberson wrote:

Well, compile under linux if you wish,

Which is a common server platform and occasionally used on desktops. It
is also the OS used on some HD DVD players and various other pieces of
consumer electronics.

buy a MACintosh,

Which is a not uncommon desktop/notebook platform and slowly becomming
more common.

You forgot to mention all the other common Unix variants which are
common in the server market.

run
your programs under Sony play station what do you want?

If you do not have stdcall probably you do not need it.

Ah, so you admit now that stdcall is specific to one specific OS do you?
That would fit a lot of peoples definitions of platform specific.

 

[Flash Gordon]

Sensei wrote, On 25/04/08 08:01:

Jacob, as a learner here I really do care about portable code, so I'd be
happy to know what is in the standard, what is specific to a platform
(or a set of), and finally what is implementation specific.

Well, this is definitely the group to find that out.

If I find a platform where "__whatever" isn't available I'd be very
unhappy using that extension since my code won't compile everywhere (so
I would produce platform specific code). Of course there is a platform
where "int winmain()" is available, and that constitutes 90% of the
desktop market, but I'd rather use "int main()". It's the same reason
why I don't see portable code using "__int32" or similar things.

My two cents of understanding the purpose of standard C.

One of the purposes of C is to provide a common language that can be
used almost everywhere. That is a purpose this group can help a lot with.

Other purposes include allowing the production of efficient code
(although neither users nor compilers are *required* to do this) and
allowing people to get down and dirty with *very* implementation
specific stuff when required (e.g. creating a pointer to a HW register
and writing to it).

 

[Nick Keighley]

"_stdcall" isn't platform-specific?  Seriously?

It depends on what you mean by "specific".  On Usenet, where everybody
wants to be a standards jockey (not just here [clc], but clc is among the
worst), there is a tendency to use the phrase "platform specific" even
if the thing works on 99% (say) of all platforms.

so do you have some evidence for 99%?
More than one poster has found platforms that don't support
it so they are pretty common. Are you including the embedded
world in this 99%?

 This is not a usage
of the word "specific" that maps to the real world, in any
other sphere of endeavor.

Programming requires precision. You can afford to be sloppy when
gardening or cooking but not when programming.

One might go on to say that people who use it in this way
are insane.

In the real world, the word "specific" usually implies uniqueness -
i.e., we would say that something is "platform specific" if it worked on
exactly 1 platform (hence, specific to that platform).

but then you run into the problem of defining "platform"

 

[santosh]

"_stdcall" isn't platform-specific?  Seriously?

It depends on what you mean by "specific".  On Usenet, where
everybody wants to be a standards jockey (not just here [clc], but
clc is among the worst), there is a tendency to use the phrase
"platform specific" even if the thing works on 99% (say) of all
platforms.

so do you have some evidence for 99%?
More than one poster has found platforms that don't support
it so they are pretty common. Are you including the embedded
world in this 99%?

This is not a usage
of the word "specific" that maps to the real world, in any
other sphere of endeavor.

Programming requires precision. You can afford to be sloppy when
gardening or cooking but not when programming.

One might go on to say that people who use it in this way
are insane.

In the real world, the word "specific" usually implies uniqueness -
i.e., we would say that something is "platform specific" if it worked
on exactly 1 platform (hence, specific to that platform).

but then you run into the problem of defining "platform"

In fact the use of _stdcall would qualify as "platform specific"
according to Kenny's own definition of that term, since it's only ever
used, as far as I'm aware, on Windows and clones, a collection that can
be, for the present purposes, considered as one platform.

 

[Nick Keighley]

Ian Collins wrote:

[the discussion was about __stdcall]

Who cares?

so its not a common extension then...

It is supported by gcc  and all the platforms gcc runs on,

I believe other posters have produced examples where this is
not so.

supported by MSVC, supported by Watcom, Borland, lcc-win,
and what have you.

That is almost 100% of the market.

dissembler. Consider embedded processors.

Obviously you use
something else and never look into mainstream computing like
many regulars here.

Ignorance is a bliss!

I told you, you are a genius.

well you aren't looking too smart at the moment...

 

[vippstar]

What's the point of showing your ignorance as it was a quality? What

You do not know the subject matter?

Just stay silent! Is that too complicated?

Don't you know the newsgroups subject?
Just stay silent! Is that too complicated?

 

[Bartc]

Just supply me with the name of one compiler for all of the following
architectures that supports this stupidity:

- ARM

- MIPS

- Any TI DSP

- Any AD DSP

- 8051

These are all typical development systems one can buy on the high street of
course!

Surely C programs should be cabable of calling non-C routines, and it makes
sense for the standard to provide a mechanism for specifying such routines,
even if it doesn't go into details.

Someone mentioned __attribute__ (although I can't see it in my C99 document,
maybe gcc-specific).

I don't see why such a function attribute couldn't have been in the C
standard, with implementations either using it or ignoring it.

There are some issues with portability, but they are no different from
making use of the 'fortran' keyword which appears to be part of C99.

 

[Bartc]

Bartc said:

In comp.lang.c, we deal with C, not just the version of C you can buy on
the high street.

Just to show there are a few of us outside of industry, academia and
business. And we are very likely to be developing on and for consumer PCs.

Are you going to tell them or shall I?

You do it, they might listen to you. Just tell them to put it in appendix J
(of C99) then it'll be alright.

Really I can't see anything wrong with this, I've written code (not in C)
that has declarations like:

callback function WinMain (int,int,ref char,int)int
clang function printf (..)
windows function MessageBoxA (int,ref char,ref char,int)int

Maybe this won't make sense on a DSP chip, but then it probably won't have
Windows on it either, a more serious shortcoming. At least it acknowledges
there are other languages and systems outside of itself. Standard C just
likes to bury it's head in the sand it seems.

It's listed as a common extension, in a non-normative appendix. This is no
more a part of the Standard than is double double.

In that case perhaps there was no reason for Appendix J at all?

 

[Joachim Schmitz]

Go to the kindergarten then. There you will find all answers

How about admitting, for a change, that you were wrong?

It doesn't hurt, really.

Bye, Jojo

 

[Joachim Schmitz]

And I showed Eric and you and Thompson that is supported
on gcc/MSVC/Lcc-win/Watcom/Borland and what have you

not on (generally) GCC and even if, not in that form.

what piss me off of this regulars is that when proved wrong
they insist

It's you, who insists (on being right), and do this on a regular basis,
regardless the opposit has been proven by more than one poster.

You are one of the very few regular( poster)s that insist on being right
when proven wrong.

Bye, Jojo

 

[Antoninus Twink]

... but you said __stdcall wasn't platform-specific, so
why do I have to write __attribute__((stdcall)) instead? And
what about the other platform I tried?

Just put

#ifndef __stdcall
#define __stdcall
#endif

at the top of your source file - then it will work on any platform.

 

[Joachim Schmitz]

Just put

#ifndef __stdcall
#define __stdcall
#endif

at the top of your source file - then it will work on any platform.

Unless that platform unconditionally #define's it in a file #include'd after
this construct...

So you'd need to put is _after_ the last #incude

 

[Ben Bacarisse]

You do it, they might listen to you. Just tell them to put it in appendix J
(of C99) then it'll be alright.

Really I can't see anything wrong with this, I've written code (not in C)
that has declarations like:

callback function WinMain (int,int,ref char,int)int
clang function printf (..)
windows function MessageBoxA (int,ref char,ref char,int)int

Maybe this won't make sense on a DSP chip, but then it probably won't have
Windows on it either, a more serious shortcoming. At least it acknowledges
there are other languages and systems outside of itself. Standard C just
likes to bury it's head in the sand it seems.

Having a standard way to do something pays off if the standard can
guarantee that it works. Otherwise there is very little point (not
no point, just very little) in making it standard.

The C committee can't mandate that, say,

__fortran matinv(double (*)[n], int n);

will have any effect at all on any fortran system out there. The
standard allows an implementation to have the keyword, and that is
probably enough. An organisation that standardised multi-language
interfaces could mandate such a thing, but the C standard can't.

It could mandate a syntax, but that would have to be so very loose as
to be almost pointless. A C compiler might need different calling
conventions to call into Frobnoz Fortran 90 than it does for GNU
Fortran 77. The best you could do is maybe extern "some string" {
.... } and hope. Would you gain much if this were in the standard?
Maybe a little, but not much.

 

[Keith Thompson]

Jacob, as a learner here I really do care about portable code, so I'd
be happy to know what is in the standard, what is specific to a
platform (or a set of), and finally what is implementation specific.

[...]

The latest (post-C99) draft of the standard is freely available at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.

Drafts of the more widely supported C90 standard are slightly harder
to come by (I'm sure someone will post a URL or two in response to
this). But since C99 is very nearly a superset of C90 (dropping
implicit int was probably the biggest exception), if a feature isn't
mentioned in n1256.pdf you can be reasonably sure that it's not in any
C standard.