__stdcall alternative

[Joachim Schmitz]

Re: __stdcall alternative

Antoninus Twink wrote:

On 24 Apr 2008 at 21:34, Eric Sosman wrote:

>jacob navia wrote:

>>If you use gcc you should
>>#ifndef STDCALL
>>#define STDCALL __attribute__(( stdcall))
>>#endif

>>
> ... 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.

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]

Re: __stdcall alternative

"Bartc" <bc@freeuk.comw rites:

"Richard Heathfield" <rjh@see.sig.in validwrote in message
news:TJSdnfqbwo Z_JIzVRVnygQA@b t.com...

>Bartc said:

>>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.

>>
>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.

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.

--
Ben.

[Keith Thompson]

Re: __stdcall alternative

Sensei <Sensei's e-mail is at Mac-dot-comwrites:
[...]

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.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kenny McCormack]

Re: __stdcall alternative

In article <fus7c7$rqi$3@r egistered.motza rella.org>,
santosh <santosh.k83@gm ail.comwrote:
....

>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.

Anyone with an IQ over 3 can see that the term "Windows" represents
many, many, different platforms.

We realize that you don't qualify.

[Flash Gordon]

Re: __stdcall alternative

Keith Thompson wrote, On 25/04/08 17:23:

Sensei <Sensei's e-mail is at Mac-dot-comwrites:
[...]

>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).

Ask and it shall be done...

http://clc-wiki.net/wiki/c_standard

It also has links to where you can find the rationales which say why
some of the C standard is the way it is.

But since C99 is very nearly a superset of C90 (dropping
implicit int was probably the biggest exception),

I would always have considered using an explicit int to be better style
anyway. Others may disagree, of course.

if a feature isn't
mentioned in n1256.pdf you can be reasonably sure that it's not in any
C standard.

True.

The most portable version of the C language is the common subset of C99
and C90.

Also Sensei should note that you normally have to supply extra options
to get any compiler to fully conform to the C standard, and sometimes
further options to make it warn/error on extensions (some will never
warn/error on every extension they support), and more options to get the
compiler to get a load more useful warnings.

In short, read the documentation and find out how to make your compiler
conform to the standard and warn about as much as possible.
--
Flash Gordon

[Sensei]

Re: __stdcall alternative

On 2008-04-25 20:50:23 +0200, Flash Gordon <spam@flash-gordon.me.uksai d:

Also Sensei should note that you normally have to supply extra options
to get any compiler to fully conform to the C standard, and sometimes
further options to make it warn/error on extensions (some will never
warn/error on every extension they support), and more options to get
the compiler to get a load more useful warnings.
>
In short, read the documentation and find out how to make your compiler
conform to the standard and warn about as much as possible.

I was just pointing out that "common extension" is not enough to me,
__stdcall so isn't a viable option. Anyway I'm not posting much, but I
am learning a lot here!

--

Sensei <Sensei's e-mail is at Mac-dot-com>

Basic research is what I am doing when I don't know what I am doing.
(Wernher von Braun)

[Flash Gordon]

Re: __stdcall alternative

Sensei wrote, On 26/04/08 13:30:

On 2008-04-25 20:50:23 +0200, Flash Gordon <spam@flash-gordon.me.uksai d:
>

>Also Sensei should note that you normally have to supply extra options

<snip>

I was just pointing out that "common extension" is not enough to me,
__stdcall so isn't a viable option. Anyway I'm not posting much, but I
am learning a lot here!

My post was not intended as criticism, merely providing information
which you may or may not have known.
--
Flash Gordon

[CBFalconer]

Re: __stdcall alternative

jacob navia wrote:

Richard Tobin wrote:

>jacob navia <jacob@nospam.o rgwrote:
>>

>>If you use gcc you should

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

>>#ifndef STDCALL
>>#define STDCALL __attribute__(( stdcall))
>>#endif

>>
>I get:
>>
>foo.c:5: warning: 'stdcall' attribute directive ignored
>>
>Presumably this is an x86-only declaration.

>
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.

Please explain how this all works on registerless machines, e.g.
something that uses only stack-ops.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

** Posted from http://www.teranews.com **

[CBFalconer]

Re: [OT] __stdcall alternative

jacob navia wrote:

Ian Collins wrote:
>

.... snip ...

>>
>What is __stdcall?

>
What's the point of showing your ignorance as it was a quality?
You do not know the subject matter?
Just stay silent! Is that too complicated?
>

>It's not C,

>
Of course it is. It is a common extension.
>

>so it must be platform specific,

>
no, it isn't

[OT] You are exposing your ignorance Jacob. One of the uses of
that word is within Winders, to specify the 'Pascal' form of
function calling (and parameter passing) as contrasted to the
so-called C-style. Neither is specified by the C standard, so the
whole matter is up to the compiler system implementor. Note that
the word is in the implementation reserved set of names.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[CBFalconer]

Re: __stdcall alternative

Joachim Schmitz wrote:

jacob navia wrote:
>

.... snip ...

>

>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.

Well, the net effect is that most users here just ignore Jacobs
pronouncements, because they KNOW he is very often wrong. Some
even plonk him.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **