I'm mixing C and ASM, and for calling ASM from C, I just happened to use the
__stdcall convention (using C convention is not practical for other
reasons).
But, __stdcall seems to assume that machine registers are saved by the
called routine (as far as I can gather after a few hours messing with some
strange behaviours especially with optimised C code).
Is there any other call convention I can use likely to be commonly
available?
Or is there a way of specifying that an external function does not save
registers or is badly behaved?
--
Thanks,
Bartc
54  7525 
Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened to use the
__stdcall convention (using C convention is not practical for other
reasons).
What is __stdcall? It's not C, so it must be platform specific, try a
group for your platform, you'll get more help there.
--
Ian Collins.
Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened to use the
__stdcall convention (using C convention is not practical for other
reasons).
But, __stdcall seems to assume that machine registers are saved by the
called routine (as far as I can gather after a few hours messing with some
strange behaviours especially with optimised C code).
OBVIOUSLY you should save the registers ytour compiler thinks are permanent
Under windows (where stdcall is commonly used) you should save
(I am assuming 64 bit CPU)
rsi
rdi
rbx
r12-r15
rbp
And at the end you should issue a
ret $8
when you receive 8 bytes of arguments for instance.
Is there any other call convention I can use likely to be commonly
available?
you could just as well use the C calling convention. The registers to save
are THE SAME but you should just issue
ret
and the called procedure adjusts the stack.
Or is there a way of specifying that an external function does not save
registers or is badly behaved?
There is NO way to do that. YOU HAVE TO SAVE THOSE if not
you will just have a crash.
>
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Ian Collins wrote:
Bartc wrote:
>I'm mixing C and ASM, and for calling ASM from C, I just happened to use the
__stdcall convention (using C convention is not practical for other
reasons).
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
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On 24 Apr 2008 at 20:56, jacob navia wrote:
Bartc wrote:
>Or is there a way of specifying that an external function does not save
registers or is badly behaved?
There is NO way to do that. YOU HAVE TO SAVE THOSE if not
you will just have a crash.
It sounded to me like the external function isn't one he's written, and
he can't control its behavior. If that's the case, there's nothing for
it except to work out what calling convention the function expects, and
use that.
jacob navia wrote:
Ian Collins wrote:
>Bartc wrote:
>>I'm mixing C and ASM, and for calling ASM from C, I just happened to
use the __stdcall convention (using C convention is not practical for
other reasons).
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
Oh, good! Then I'll start using it right away!
% cat foo.c
extern void __stdcall foo(void);
% cc foo.c
"foo.c", line 1: syntax error before or at: foo
"foo.c", line 1: warning: old-style declaration or incorrect type for: foo
cc: acomp failed for foo.c
%
Hmmm -- Something seems to be amiss. I'll try a
different machine and a different compiler:
>gcc foo.c
foo.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'foo'
What am I doing wrong? You've said __stdcall isn't
platform-specific, but I've tried two platforms and it doesn't
work on either of them!
-- Er*********@sun.com
jacob navia <ja***@nospam.comwrites:
Ian Collins wrote:
>Bartc wrote:
>>I'm mixing C and ASM, and for calling ASM from C, I just happened
to use the __stdcall convention (using C convention is not
practical for other reasons).
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
"_stdcall" isn't platform-specific? Seriously?
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Eric Sosman wrote:
jacob navia wrote:
>Ian Collins wrote:
>>Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened to
use the __stdcall convention (using C convention is not practical
for other reasons).
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
Oh, good! Then I'll start using it right away!
% cat foo.c
extern void __stdcall foo(void);
% cc foo.c
"foo.c", line 1: syntax error before or at: foo
"foo.c", line 1: warning: old-style declaration or incorrect type for: foo
cc: acomp failed for foo.c
%
Hmmm -- Something seems to be amiss. I'll try a
different machine and a different compiler:
>gcc foo.c
foo.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'foo'
What am I doing wrong? You've said __stdcall isn't
platform-specific, but I've tried two platforms and it doesn't
work on either of them!
If you use gcc you should
#ifndef STDCALL
#define STDCALL __attribute__((stdcall))
#endif
>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?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
>Ian Collins wrote:
>>Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened
to use the __stdcall convention (using C convention is not
practical for other reasons).
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
"_stdcall" isn't platform-specific? Seriously?
#ifndef STDCALL
#define STDCALL __attribute__((stdcall))
#endif
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
Eric Sosman wrote:
>jacob navia wrote:
>>Ian Collins wrote:
Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened
to use the __stdcall convention (using C convention is not
practical for other reasons).
>
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
Oh, good! Then I'll start using it right away!
% cat foo.c
extern void __stdcall foo(void);
% cc foo.c
"foo.c", line 1: syntax error before or at: foo
"foo.c", line 1: warning: old-style declaration or incorrect type for:
foo
cc: acomp failed for foo.c
%
Hmmm -- Something seems to be amiss. I'll try a
different machine and a different compiler:
> >gcc foo.c
foo.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'foo'
What am I doing wrong? You've said __stdcall isn't
platform-specific, but I've tried two platforms and it doesn't
work on either of them!
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?
-- Er*********@sun.com
jacob navia <ja***@nospam.comwrites:
Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites:
>>Ian Collins wrote:
Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened
to use the __stdcall convention (using C convention is not
practical for other reasons).
>
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
"_stdcall" isn't platform-specific? Seriously?
#ifndef STDCALL
#define STDCALL __attribute__((stdcall))
#endif
What does defining "STDCALL" have to do with "__stdcall"? They're two
different identifiers, you know.
I suppose your point is that gcc supports a feature that's similar to
"__stdcall", but uses the syntax "__attribute__((stdcall))". So two
different platforms support a similar feature using radically
different syntax. If I were sufficiently motivated, I'm sure I could
find another platform that either supports it with yet another
different syntax, or doesn't support it at all.
"__stdcall" is platform-specific.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacob navia wrote:
Ian Collins wrote:
>Bartc wrote:
>>I'm mixing C and ASM, and for calling ASM from C, I just happened to
use the __stdcall convention (using C convention is not practical for
other reasons).
What is __stdcall?
Just stay silent! Is that too complicated?
Fool, if you read the bit of my post you snipped - "try a group for your
platform, you'll get more help there." - you would see I was attempting
to help the OP.
>
>It's not C,
Of course it is. It is a common extension.
Not on any platform I use, and that's quite a few.
>so it must be platform specific,
no, it isn't
Eric's already shown you that is is.
--
Ian Collins.
Eric Sosman wrote:
... 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?
Go to the kindergarten then. There you will find all answers
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
>Keith Thompson wrote:
>>jacob navia <ja***@nospam.comwrites:
Ian Collins wrote:
Bartc wrote:
>I'm mixing C and ASM, and for calling ASM from C, I just happened
>to use the __stdcall convention (using C convention is not
>practical for other reasons).
>>
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
"_stdcall" isn't platform-specific? Seriously?
#ifndef STDCALL
#define STDCALL __attribute__((stdcall))
#endif
What does defining "STDCALL" have to do with "__stdcall"? They're two
different identifiers, you know.
I suppose your point is that gcc supports a feature that's similar to
"__stdcall", but uses the syntax "__attribute__((stdcall))". So two
different platforms support a similar feature using radically
different syntax. If I were sufficiently motivated, I'm sure I could
find another platform that either supports it with yet another
different syntax, or doesn't support it at all.
"__stdcall" is platform-specific.
What piss me off of this regulars is that when they are proved
wrong they insist
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Ian Collins wrote:
jacob navia wrote:
>Ian Collins wrote:
>>Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened to
use the __stdcall convention (using C convention is not practical for
other reasons).
What is __stdcall?
Just stay silent! Is that too complicated?
Fool, if you read the bit of my post you snipped - "try a group for your
platform, you'll get more help there." - you would see I was attempting
to help the OP.
>>It's not C,
Of course it is. It is a common extension.
Not on any platform I use, and that's quite a few.
>>so it must be platform specific,
no, it isn't
Eric's already shown you that is is.
And I showed Eric and you and Thompson that is supported
on gcc/MSVC/Lcc-win/Watcom/Borland and what have you
what piss me off of this regulars is that when proved wrong
they insist
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
Ian Collins wrote:
>jacob navia wrote:
>>Ian Collins wrote:
>>>so it must be platform specific,
no, it isn't
Eric's already shown you that is is.
And I showed Eric and you and Thompson that is supported
on gcc/MSVC/Lcc-win/Watcom/Borland and what have you
Which are specific platforms, so?
what piss me off of this regulars is that when proved wrong
they insist
On what?
--
Ian Collins.
Ian Collins wrote:
Fool,
Well, You are a genius...
if you read the bit of my post you snipped - "try a group for your
platform, you'll get more help there." - you would see I was attempting
to help the OP.
You were attempting to help the original poster by
showing your ignorance.
Yes of course it helps him when you say you do not know the
subject matter.
Obviously, this proves that you are a genius.
>>It's not C,
Of course it is. It is a common extension.
Not on any platform I use, and that's quite a few.
Who cares?
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.
Ignorance is a bliss!
I told you, you are a genius.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
In article <fu**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>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.
-- Richard
--
:wq
"jacob navia" <ja***@nospam.comwrote in message
news:fu**********@aioe.org...
Bartc wrote:
>But, __stdcall seems to assume that machine registers are saved by the
called routine (as far as I can gather after a few hours messing with
some strange behaviours especially with optimised C code).
OBVIOUSLY you should save the registers ytour compiler thinks are
permanent
Under windows (where stdcall is commonly used) you should save
(I am assuming 64 bit CPU)
rsi
rdi
rbx
r12-r15
rbp
OK, for x86-32 then I have to worry about esi,edi,ebx.
you could just as well use the C calling convention. The registers to save
are THE SAME
The ASM is emitted by a compiler of mine from years back; I'm not going to
change it! I'll just stick in some bits of inline asm for now.
This is just a temporary measure until my project is 100% C. Or it will have
some ASM calling C which is a bit easier.
but you should just issue ret
and the called procedure adjusts the stack.
(That always seemed a crazy way to do things; one extra instruction /per
call/).
--
Bart
jacob navia <ja***@nospam.comwrites:
Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites:
>>Keith Thompson wrote:
jacob navia <ja***@nospam.comwrites:
Ian Collins wrote:
>Bartc wrote:
>>I'm mixing C and ASM, and for calling ASM from C, I just happened
>>to use the __stdcall convention (using C convention is not
>>practical for other reasons).
>>>
>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
"_stdcall" isn't platform-specific? Seriously?
#ifndef STDCALL
#define STDCALL __attribute__((stdcall))
#endif
What does defining "STDCALL" have to do with "__stdcall"? They're two
different identifiers, you know.
I suppose your point is that gcc supports a feature that's similar to
"__stdcall", but uses the syntax "__attribute__((stdcall))". So two
different platforms support a similar feature using radically
different syntax. If I were sufficiently motivated, I'm sure I could
find another platform that either supports it with yet another
different syntax, or doesn't support it at all.
"__stdcall" is platform-specific.
What piss me off of this regulars is that when they are proved
wrong they insist
Either I'm missing something, or you haven't done anything that
resembles proving me wrong.
I say __stdcall is platform-specific. You say it isn't. Fine, then
convince me that you're right. If you do, then I'll gladly admit it
(I admit to my mistakes here on a fairly regular basis).
What do you mean by "platform-specific", and how does that concept
*not* apply to __stdcall? Is it supported on all platforms?
I asked about "__stdcall"; you replied with macro named "STDCALL".
Are they intended to be the same thing?
Don't waste your time and ours by telling us that you're pissed off
because somebody disagrees with you. If you're right, demonstrate it.
(And by the way, this isn't about you; I'd say the same thing if
anyone else made the same claim.)
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Bartc wrote:
"jacob navia" <ja***@nospam.comwrote in message
news:fu**********@aioe.org...
>Bartc wrote:
>>But, __stdcall seems to assume that machine registers are saved by the
called routine (as far as I can gather after a few hours messing with
some strange behaviours especially with optimised C code).
OBVIOUSLY you should save the registers ytour compiler thinks are
permanent
Under windows (where stdcall is commonly used) you should save
(I am assuming 64 bit CPU)
rsi
rdi
rbx
r12-r15
rbp
OK, for x86-32 then I have to worry about esi,edi,ebx.
AND EBP!!!
>
>you could just as well use the C calling convention. The registers to save
are THE SAME
The ASM is emitted by a compiler of mine from years back; I'm not going to
change it! I'll just stick in some bits of inline asm for now.
If your compiler was able to interface with outside code, it surely
saved those. It is very simple
push esi
push ebx
push edi
....
pop edi
pop ebx
pop esi
and you are all set
This is just a temporary measure until my project is 100% C. Or it will have
some ASM calling C which is a bit easier.
>but you should just issue ret
and the called procedure adjusts the stack.
(That always seemed a crazy way to do things; one extra instruction /per
call/).
It saves 5% code space, it is very efficient.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
In article <fu**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>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/Fu...ion-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... ?
--
"I buy more from my grocer than he buys from me, and I bet it's
the same with you and your grocer. That means we have a trade
deficit with our grocers. Does our perpetual grocer trade deficit
portend doom?" -- Walter Williams
Richard Tobin wrote:
In article <fu**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>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.
-- 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
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
Ian Collins wrote:
>jacob navia wrote:
>>Ian Collins wrote:
Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened to
use the __stdcall convention (using C convention is not practical for
other reasons).
>
What is __stdcall?
Just stay silent! Is that too complicated?
Fool, if you read the bit of my post you snipped - "try a group for your
platform, you'll get more help there." - you would see I was attempting
to help the OP.
>>>It's not C,
Of course it is. It is a common extension.
Not on any platform I use, and that's quite a few.
>>>so it must be platform specific,
no, it isn't
Eric's already shown you that is is.
And I showed Eric and you and Thompson that is supported
on gcc/MSVC/Lcc-win/Watcom/Borland and what have you
No, you showed ("claimed," actually) something about
just one of these compilers, namely, that they support
__attribute__((stdcall)). Even if we take your word for it,
there are still the problems
1) __attribute__((stdcall)) is not __stdcall. Count
the keystrokes if you disagree.
2) The one compiler for which you made the claim, and
even the extended list for which you have "shown"
nothing at all, are not the totality of all platforms.
In particular, you still haven't shown how to use
__stdcall on the first compiler I tried it with.
(I don't need to identify the compiler for you,
because if __stdcall isn't platform-specific it will
work the same way on the unidentified compiler as on
any other.)
what piss me off of this regulars is that when proved wrong
they insist
.... on complete, coherent sentences leading to conclusions
that you find embarrassing?
-- Er*********@sun.com
Walter Roberson wrote:
In article <fu**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>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/Fu...ion-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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
Ian Collins wrote:
>if you read the bit of my post you snipped - "try a group for your
platform, you'll get more help there." - you would see I was attempting
to help the OP.
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?
>>>It's not C,
Of course it is. It is a common extension.
Not on any platform I use, and that's quite a few.
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.
--
Ian Collins.
Keith Thompson wrote, On 24/04/08 22:51:
jacob navia <ja***@nospam.comwrites:
>Keith Thompson wrote:
>>jacob navia <ja***@nospam.comwrites:
Ian Collins wrote:
Bartc wrote:
>I'm mixing C and ASM, and for calling ASM from C, I just happened
>to use the __stdcall convention (using C convention is not
>practical for other reasons).
>>
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
"_stdcall" isn't platform-specific? Seriously?
#ifndef STDCALL
#define STDCALL __attribute__((stdcall))
#endif
What does defining "STDCALL" have to do with "__stdcall"? They're two
different identifiers, you know.
I suppose your point is that gcc supports a feature that's similar to
"__stdcall", but uses the syntax "__attribute__((stdcall))". So two
different platforms support a similar feature using radically
different syntax. If I were sufficiently motivated, I'm sure I could
find another platform that either supports it with yet another
different syntax, or doesn't support it at all.
"__stdcall" is platform-specific.
markg@hal02 ~ $ cat t.c
#ifndef STDCALL
#define STDCALL __attribute__((stdcall))
#endif
extern void STDCALL foo(void);
markg@hal02 ~ $ gcc -c t.c
t.c:4: warning: `stdcall' attribute directive ignored
markg@hal02 ~ $
Admittedly that is not an x86 based system. So just in case it is
specific to the processor type lets try on one of my x86 based systems...
On another system:
-bash-2.05b$ cc t.c
UX:i386acomp: ERROR: "t.c", line 4: error: Syntax error before or at: (
UX:i386acomp: ERROR: "t.c", line 4: error: cannot recover from previous
errors
-bash-2.05b$ cat tt.c
#ifndef STDCALL
#define STDCALL __stdcall
#endif
extern void STDCALL foo(void);
-bash-2.05b$ cc tt.c
UX:i386acomp: ERROR: "tt.c", line 4: error: syntax error, probably
missing ",", ";" or "="
UX:i386acomp: ERROR: "tt.c", line 4: error: Syntax error before or at: foo
UX:i386acomp: WARNING: "tt.c", line 4: warning: declaration missing
specifiers: assuming "int"
-bash-2.05b$
Nope, doesn't work on all x86 based systems either.
So Keith and Ian are correct to say it is platform specific.
--
Flash Gordon
In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:
....
>no, it isn't
"_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. 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).
On Thu, 24 Apr 2008 22:59:10 +0200, jacob navia <ja***@nospam.com>
wrote in comp.lang.c:
Ian Collins wrote:
Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened to use the
__stdcall convention (using C convention is not practical for other
reasons).
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.
Perhaps by your definition of "common". It doesn't exist on more than
90% of the current C compilers in existence, only on the half-a-dozen
or so for Windows.
so it must be platform specific,
no, it isn't
Yes, it is.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
On Fri, 25 Apr 2008 00:07:23 +0200, jacob navia <ja***@nospam.com>
wrote in comp.lang.c:
Ian Collins wrote:
jacob navia wrote:
Ian Collins wrote:
Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened to
use the __stdcall convention (using C convention is not practical for
other reasons).
What is __stdcall?
Just stay silent! Is that too complicated?
Fool, if you read the bit of my post you snipped - "try a group for your
platform, you'll get more help there." - you would see I was attempting
to help the OP.
>It's not C,
Of course it is. It is a common extension.
Not on any platform I use, and that's quite a few.
>so it must be platform specific,
no, it isn't
Eric's already shown you that is is.
And I showed Eric and you and Thompson that is supported
on gcc/MSVC/Lcc-win/Watcom/Borland and what have you
OK, that's less than 5% of all the current C compilers in existence.
And all for one specific processor architecture. Anything that is
specific to one processor architecture is platform specific.
what piss me off of this regulars is that when proved wrong
they insist
What pisses me off about idiots like you is that when they are proven
wrong they just get belligerent and start insulting people.
Learn this definition:
Anything not available on every conforming C implementation is
platform specific.
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
....but what's the point of going on, no amount of common sense or
logic will ever penetrate your ego.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
"Bartc" <bc@freeuk.comwrote in message
news:QE*****************@text.news.virginmedia.com ...
"jacob navia" <ja***@nospam.comwrote in message
news:fu**********@aioe.org...
>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
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
Jack Klein said:
On Fri, 25 Apr 2008 00:07:23 +0200, jacob navia <ja***@nospam.com>
wrote in comp.lang.c:
<snip>
>what piss me off of this regulars is that when proved wrong
they insist
What pisses me off about idiots like you is that when they are proven
wrong they just get belligerent and start insulting people.
Someone else finally noticed, I see. The trouble is, though, Jack, that
from now on, whenever you correct his idiocies, you'll be accused of
carrying out a vendetta against him. And eventually, you'll get sick and
tired of that, and you'll stop correcting him. And then someone else will
finally realise that the guy is posting nonsense, and /he/ will start
posting corrections, and /he/ will be accused of conducting a vendetta,
and round and round it will go. I was going to add "ad nauseam", but we
may well be past that stage already.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
jacob navia wrote, On 24/04/08 23:32:
Walter Roberson wrote:
<snip Jacob erroneously claiming __stdcall is not platform specific>
And for those of us not using gcc and not compiling on Windows... ?
>
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
On 2008-04-25 00:12:42 +0200, jacob navia <ja***@nospam.comsaid:
Who cares?
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.
Ignorance is a bliss!
I told you, you are a genius.
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.
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.
Bye!
--
Sensei*<Sensei's e-mail is at Mac-dot-com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)
Sensei wrote, On 25/04/08 08:01:
<snip>
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).
--
Flash Gordon
On 25 Apr, 00:31, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:
In article <87y773rlvi....@kvetch.smov.org>,
Keith Thompson *<ks...@mib.orgwrote:
"_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"
--
Nick Keighley
Nick Keighley wrote:
On 25 Apr, 00:31, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:
>In article <87y773rlvi....@kvetch.smov.org>,
Keith Thompson *<ks...@mib.orgwrote:
>"_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.
On 24 Apr, 23:12, jacob navia <ja...@nospam.comwrote:
Ian Collins wrote:
[the discussion was about __stdcall]
>It's not C,
Of course it is. It is a common extension.
Not on any platform I use, and that's quite a few.
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...
--
Nick Keighley
On Apr 24, 11:59 pm, jacob navia <ja...@nospam.comwrote:
Ian Collins wrote:
Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened to use the
__stdcall convention (using C convention is not practical for other
reasons).
What is __stdcall?
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?
"Jack Klein" <ja*******@spamcop.netwrote in message
news:p5********************************@4ax.com...
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.
--
Bart
Bartc said:
>
"Jack Klein" <ja*******@spamcop.netwrote in message
news:p5********************************@4ax.com...
>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!
In comp.lang.c, we deal with C, not just the version of C you can buy on
the high street.
>
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?
>
Someone mentioned __attribute__ (although I can't see it in my C99
document, maybe gcc-specific).
The __attribute__ identifier is reserved for use by implementations. Each
implementation is free to define it in its own way, with its own semantics
(which need have no connection whatsoever with gcc semantics), or not to
define it at all.
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.
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.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:TJ*********************@bt.com...
Bartc said:
>"Jack Klein" <ja*******@spamcop.netwrote in message
news:p5********************************@4ax.com.. .
>>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!
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.
>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.
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?
--
Bart
jacob navia wrote:
Eric Sosman wrote:
> ... 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?
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
jacob navia wrote:
Ian Collins wrote:
>jacob navia wrote:
>>Ian Collins wrote:
Bartc wrote:
I'm mixing C and ASM, and for calling ASM from C, I just happened
to use the __stdcall convention (using C convention is not
practical for other reasons).
>
What is __stdcall?
Just stay silent! Is that too complicated?
Fool, if you read the bit of my post you snipped - "try a group for
your platform, you'll get more help there." - you would see I was
attempting to help the OP.
>>>It's not C,
Of course it is. It is a common extension.
Not on any platform I use, and that's quite a few.
>>>so it must be platform specific,
no, it isn't
Eric's already shown you that is is.
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
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.
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
"Bartc" <bc@freeuk.comwrites:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:TJ*********************@bt.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.
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_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
In article <fu**********@registered.motzarella.org>,
santosh <sa*********@gmail.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.
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Ed |
last post by:
Suppose I want a function a pointer to which is going to
be passed to another function to use __stdcall conventions.
That is, I want the call to cbFunc() in tryCB3() to be compiled
for __stdcall...
|
by: Eric Twietmeyer |
last post by:
Hello,
I am wondering how it is that all of the windows base dlls, like
kernel32.dll specify that all of their functions are __stdcall and yet the
exported names from the dll are not decorated...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
