Making C better (by borrowing from C++)

[CBFalconer]

Thinking about it, it's quite possible for a compiler to use two
different calling conventions automatically. If it's a variadic
function, or (in C90) has a null prototype (), the calling code
pops the parameters, otherwise the called function pops them. If
a function has a fixed number of parameters (as anything using
_stdcall must do) this this is not a problem.

If there isn't a prototype in scope at the time of the function call,
assume whichever you like and issue a warning, it's te programmer's
problem...

As another ferexample, you can have a macro in stdio.h that reads:

#define printf _funnycall _xprintf

with whatever implementations specific action you wish from
_funnycall. _xprintf will be written to do the actual work. With
C99 variadic macros you can carry this further by including the
parameters to printf in xprintf.

 

[Richard Bos]

All API functions under win32 use the _stdcall calling convention.

They'd better not. I'm allowed to do this:

int func(void)
{
int _stdcall=4;
return _stdcall;
}

Oh, perhaps you meant to say that those functions _aren't ISO C_? Gosh,
what a surprise.

[ Snip rest of off-topic nonsense. ]

Richard

 

[jacob navia]

All API functions under win32 use the _stdcall calling convention.

They'd better not. I'm allowed to do this:

int func(void)
{
int _stdcall=4;
return _stdcall;
}

Oh, perhaps you meant to say that those functions _aren't ISO C_? Gosh,
what a surprise.

[ Snip rest of off-topic nonsense. ]

Richard

Go tell that to Bill Gates Mr Boss.

[ Snip rest of off-topic nonsense. ]

You aren't able to argument anything anyway.
That would suppose making an intellectual effort and
try to explain your views.

 

[Mark McIntyre]

All API functions under win32 use the _stdcall calling convention.

Oh, perhaps you meant to say that those functions _aren't ISO C_? Gosh,
what a surprise.

[ Snip rest of off-topic nonsense. ]

Go tell that to Bill Gates Mr Boss.

I'm trying to work out if you're being deliberately stupid, or merely
accidentally so. Are you trying to claim that Windows API calls are
standard C, or that somehow invoking Bill Gates' name will make them so, or
what?

 

[Richard Bos]

All API functions under win32 use the _stdcall calling convention.

They'd better not. I'm allowed to do this:

int func(void)
{
int _stdcall=4;
return _stdcall;
}

Oh, perhaps you meant to say that those functions _aren't ISO C_? Gosh,
what a surprise.

[ Snip rest of off-topic nonsense. ]

Richard

Go tell that to Bill Gates

Bill Gates doesn't post his non-conforming code to c.l.c.

Mr Boss.

Grow up...

[ Snip rest of off-topic nonsense. ]

....and get a brain. You didn't snip a single byte of my post.

You aren't able to argument anything anyway.
That would suppose making an intellectual effort and
try to explain your views.

I've done that in the past. And again, and again, and again. If you want
to review all my arguments for why "your" compiler is off-topic here, go
to DejaGoogle; I'm not going to rehash them yet another time. Every now
and then it still is a good idea to point out that your extensions are
off-topic in this newsgroup (and that you have a whole shining,
sparkling newsgroup for lcc to play around in), both for your own
edification and that of any lurkers; but if you haven't understood _why_
by now, you probably never will.

Richard

 

[Chris Hills]

All API functions under win32 use the _stdcall calling convention.

They'd better not. I'm allowed to do this:

int func(void)
{
int _stdcall=4;
return _stdcall;
}

Oh, perhaps you meant to say that those functions _aren't ISO C_? Gosh,
what a surprise.

[ Snip rest of off-topic nonsense. ]

Richard

Go tell that to Bill Gates Mr Boss.

Who cares what MS does? the majority of C programming is not for a
Windows target anyway.

Are you saying the MS does NOT produce a C compiler but something of
their own that does not conform to international standards?

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ (e-mail address removed) www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

 

[Dave Thompson]

On Sun, 20 Feb 2005 11:45:23 +0000, Chris Croughton

Thinking about it, it's quite possible for a compiler to use two
different calling conventions automatically. If it's a variadic
function, or (in C90) has a null prototype (), the calling code pops the
parameters, otherwise the called function pops them. If a function has
a fixed number of parameters (as anything using _stdcall must do) this
this is not a problem.

Variadic, yes. A variadic function can legally be called only if a
prototype for it is in scope, so it can use a different calling
convention. I have used such a system, where the platform's 'native'
calling convention, used for fixed-args, was unsuitable for variadic.

Unprototyped, no. (Strictly speaking, empty parens aren't a 'null
prototype' in C, they're an empty old-style identifier-list.) It is
legal and must work for some call(s) to a function to use a prototype
and other call(s) to use a nonprototype declaration as long as the
default-promoted actual argument types are right (or in C90 with no
declaration if also the return type is int).

Well, you could use variant entrypoints or jackets, since (the
compiler at) each callsite knows which it is using; or you could have
the different conventions explicitly pass flag information saying
which was used. But that's just making things more complicated (harder
to maintain) and less efficient for no benefit. DS9k here we come.


- David.Thompson1 at worldnet.att.net