Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13871 > unrolled thread

Variables allocated on stack

Back to article view | Back to comp.lang.c

Contents

  Variables allocated on stack Bogdan <cristeab@gmail.com> - 2011-11-24 13:28 -0800
    Re: Variables allocated on stack Ian Collins <ian-news@hotmail.com> - 2011-11-25 10:40 +1300
    Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-24 23:30 +0100
      Re: Variables allocated on stack Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-12-02 22:33 +0000
        Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-12-03 00:54 +0100
        Re: Variables allocated on stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-02 23:33 -0800
          Re: Variables allocated on stack Keith Thompson <kst-u@mib.org> - 2011-12-03 02:25 -0800
    Re: Variables allocated on stack jt@toerring.de (Jens Thoms Toerring) - 2011-11-24 23:37 +0000
    Re: Variables allocated on stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-25 01:53 -0800
      Re: Variables allocated on stack "BartC" <bc@freeuk.com> - 2011-11-25 11:05 +0000
        Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-25 12:11 +0100
          Re: Variables allocated on stack "BartC" <bc@freeuk.com> - 2011-11-25 11:40 +0000
            Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-25 12:52 +0100
              Re: Variables allocated on stack Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-27 02:31 -0800
                Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-27 13:28 +0100
                Re: Variables allocated on stack André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-11-27 13:44 +0100
                  Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-27 15:44 +0100
                    Re: Variables allocated on stack André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-11-27 17:34 +0100
                      Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-27 18:28 +0100
                        Re: Variables allocated on stack Ian Collins <ian-news@hotmail.com> - 2011-11-28 07:48 +1300
                          Re: Variables allocated on stack gwowen <gwowen@gmail.com> - 2011-11-29 01:11 -0800
                            Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-29 17:02 +0100
            Re: Variables allocated on stack Seebs <usenet-nospam@seebs.net> - 2011-11-26 07:21 +0000
              Re: Variables allocated on stack "BartC" <bc@freeuk.com> - 2011-11-26 11:07 +0000
                Re: Variables allocated on stack Markus Wichmann <nullplan@gmx.net> - 2011-11-26 21:16 +0100
                  Re: Variables allocated on stack "BartC" <bc@freeuk.com> - 2011-11-26 23:00 +0000
                    Re: Variables allocated on stack Ian Collins <ian-news@hotmail.com> - 2011-11-27 12:12 +1300
                      Re: Variables allocated on stack "BartC" <bc@freeuk.com> - 2011-11-26 23:35 +0000
                        Re: Variables allocated on stack Ian Collins <ian-news@hotmail.com> - 2011-11-27 12:48 +1300
                        Re: Variables allocated on stack Markus Wichmann <nullplan@gmx.net> - 2011-11-27 10:56 +0100
                          Re: Variables allocated on stack Keith Thompson <kst-u@mib.org> - 2011-11-28 16:17 -0800
                            Re: Variables allocated on stack Markus Wichmann <nullplan@gmx.net> - 2011-11-30 17:04 +0100
                              Re: Variables allocated on stack Keith Thompson <kst-u@mib.org> - 2011-11-30 09:36 -0800
                                Re: Variables allocated on stack Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 05:11 -0800
                                  Re: Variables allocated on stack Keith Thompson <kst-u@mib.org> - 2012-01-25 12:23 -0800
                                    Re: Variables allocated on stack Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 19:11 -0800
                      Re: Variables allocated on stack Ian Collins <ian-news@hotmail.com> - 2011-11-27 13:06 +1300
                  Re: Variables allocated on stack André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-11-27 11:20 +0100
                    Re: Variables allocated on stack David Thompson <dave.thompson2@verizon.net> - 2012-01-19 02:43 -0500
                Re: Variables allocated on stack Seebs <usenet-nospam@seebs.net> - 2011-11-28 08:32 +0000
      Re: Variables allocated on stack Bogdan <cristeab@gmail.com> - 2011-11-26 01:18 -0800
        Re: Variables allocated on stack Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-26 08:36 -0500
    Re: Variables allocated on stack Seebs <usenet-nospam@seebs.net> - 2011-11-26 07:21 +0000
    Re: Variables allocated on stack Noob <root@127.0.0.1> - 2011-11-29 11:51 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#14029

On Nov 27, 6:48 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> > Since 32 bit linux is quite dated, I just didn't think that it was
> > necessary to specify that.
>
> Far from dated.  Most targets for embedded Linux are 32 bit (ARM, PPC).

Ian, its *Jacob*.  He doesn't acknowledge the existence of any sort of
embedded development except as a tiny niche market inhabited almost
entirely by Windows-hating by Luddites.

[toc] | [prev] | [next] | [standalone]

#14042

Le 29/11/11 10:11, gwowen a écrit :
> On Nov 27, 6:48 pm, Ian Collins<ian-n...@hotmail.com>  wrote:
>>> Since 32 bit linux is quite dated, I just didn't think that it was
>>> necessary to specify that.
>>
>> Far from dated.  Most targets for embedded Linux are 32 bit (ARM, PPC).
>
> Ian, its *Jacob*.  He doesn't acknowledge the existence of any sort of
> embedded development except as a tiny niche market inhabited almost
> entirely by Windows-hating by Luddites.

lcc-win has been ported to several 16 bits DSPs.

You are just insulting me because it is fun for you, like many
people here.

[toc] | [prev] | [next] | [standalone]

#13909

On 2011-11-25, BartC <bc@freeuk.com> wrote:
> Fair enough. In that case it's just another way to push those parameters, 
> via registers, leaving it to the callee to do the actual pushing. With the 
> advantage that the callee will know when it is possible to avoid pushing 
> onto the stack.

Yes.

> The disadvantage for the caller might be a little more effort, for the 
> compiler, in evaluating complex parameters and ensuring those registers 
> already loaded are preserved. For example:

>  fn(f(p,q,r), g(s), h(t,u,v), i());

> Here, purely stack-based parameters would be far simpler.

Right.

But you don't always get a vote -- the ABI may have specified the rules
for you.  And in fact, often has.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#13915

"Seebs" <usenet-nospam@seebs.net> wrote in message 
news:slrnjd12fr.1q65.usenet-nospam@guild.seebs.net...
> On 2011-11-25, BartC <bc@freeuk.com> wrote:

>>  fn(f(p,q,r), g(s), h(t,u,v), i());
>
>> Here, purely stack-based parameters would be far simpler.
>
> Right.
>
> But you don't always get a vote -- the ABI may have specified the rules
> for you.  And in fact, often has.

Surely compiler writers can do what they like - within their own 
implementation? Calling conventions are only important when calling foreign 
and OS functions, and being called from outside.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13928

On 26.11.2011 12:07, BartC wrote:

> Surely compiler writers can do what they like - within their own 
> implementation? Calling conventions are only important when calling foreign 
> and OS functions, and being called from outside.
> 

Yeah, that's right!

Only... every function not defined "static" may be called "from the
outside". Every call to a function only declared (and not qualified
"static") but not defined may be to a foreign function.

Plus, when you ask a compiler writer whether he want's to include
_two_different_ calling conventions in his compiler with the added
maintenance and stuff, guess what he'll say. Writing a register
allocator is hard enough without having to differentiate internal and
external functions and function calls.

CYA,
Markus

[toc] | [prev] | [next] | [standalone]

#13931

"Markus Wichmann" <nullplan@gmx.net> wrote in message
news:l2u7q8-m8a.ln1@voyager.wichi.de.vu...
> On 26.11.2011 12:07, BartC wrote:
>
>> Surely compiler writers can do what they like - within their own
>> implementation? Calling conventions are only important when calling
>> foreign
>> and OS functions, and being called from outside.
>>
>
> Yeah, that's right!
>
> Only... every function not defined "static" may be called "from the
> outside". Every call to a function only declared (and not qualified
> "static") but not defined may be to a foreign function.

If no special attributes are defined, then it is just the private calling 
convention used by this compiler. Although it might have a few other 
conventions up it's sleeve, for example when creating exported functions 
accessed via dynamic library by other languages, or calling the OS.

I'm used anyway to declaring in my non-C language:

clang function puts (istring)
windows function Sleep(int)

That is, specify the calling conventions used by these imported functions 
(in this case, also imported via DLL files). Although I believe Windows was 
originally written in C, it uses a different call convention from actual C 
programs.

Fortunately the only C functions I've had to import so far all use a 
consistent call convention. So for functions shared across applications, 
this would be a good idea. But should this be defined by the ABI? I 
understood an ABI was mainly for interfacing to the OS; it was not 
necessarily a standard for C language compilers. Or, since other languages 
are available, for *every* implementation of *every* language for that 
platform.

> Plus, when you ask a compiler writer whether he want's to include
> _two_different_ calling conventions in his compiler with the added
> maintenance and stuff, guess what he'll say.

Isn't that what happens anyway, when calling a function in a different
language? (pascal, stdcall and so on.) (And I'm working right now on a 
project with I think 4 different conventions to take care of. It's not that 
big a deal. More difficult is matching and converting datatypes across 
languages.)

> Writing a register
> allocator is hard enough without having to differentiate internal and
> external functions and function calls.

Most code generation should be for functions following the chosen
call-convention of the compiler. This may well have been chosen to be easier
to compile for. Only actual calls to other conventions, or 'callback'
functions, might need some work.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13932

On 11/27/11 12:00 PM, BartC wrote:
> "Markus Wichmann"<nullplan@gmx.net>  wrote:
>
>> Plus, when you ask a compiler writer whether he want's to include
>> _two_different_ calling conventions in his compiler with the added
>> maintenance and stuff, guess what he'll say.
>
> Isn't that what happens anyway, when calling a function in a different
> language? (pascal, stdcall and so on.)

No.  At least not on any of the platforms I'm familiar with.  Other 
languages know how to call C (so they can access the platform's services).

> (And I'm working right now on a
> project with I think 4 different conventions to take care of. It's not that
> big a deal. More difficult is matching and converting datatypes across
> languages.)

Yet again the convention is to describe those structures in C calling ABI.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13934

"Ian Collins" <ian-news@hotmail.com> wrote in message
news:9jda3mF4d0U13@mid.individual.net...
> On 11/27/11 12:00 PM, BartC wrote:
>> "Markus Wichmann"<nullplan@gmx.net>  wrote:
>>
>>> Plus, when you ask a compiler writer whether he want's to include
>>> _two_different_ calling conventions in his compiler with the added
>>> maintenance and stuff, guess what he'll say.
>>
>> Isn't that what happens anyway, when calling a function in a different
>> language? (pascal, stdcall and so on.)
>
> No.  At least not on any of the platforms I'm familiar with.

So how do you call Pascal, Fortran, (or C++) etc from C on your platform? Do
you not need to tell it that that imported function is in a different
language?

> Other languages know how to call C (so they can access the platform's
> services).

The platform interface should be language-independent. This is where a
binary interface becomes useful. (C has done a good job here in past, in 
defining such interfaces, but there is often confusion; is 'long' 32-bits or 
64-bits for example? gcc for Windows says 32, gcc for Linux says 64.)

But should a complex, register-based interface (I believe this might be for
x86-64) be also used as the standard when one C function calls another C
function in the same application?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13935

On 11/27/11 12:35 PM, BartC wrote:
> "Ian Collins"<ian-news@hotmail.com>  wrote in message
> news:9jda3mF4d0U13@mid.individual.net...
>> On 11/27/11 12:00 PM, BartC wrote:
>>> "Markus Wichmann"<nullplan@gmx.net>   wrote:
>>>
>>>> Plus, when you ask a compiler writer whether he want's to include
>>>> _two_different_ calling conventions in his compiler with the added
>>>> maintenance and stuff, guess what he'll say.
>>>
>>> Isn't that what happens anyway, when calling a function in a different
>>> language? (pascal, stdcall and so on.)
>>
>> No.  At least not on any of the platforms I'm familiar with.
>
> So how do you call Pascal, Fortran, (or C++) etc from C on your platform? Do
> you not need to tell it that that imported function is in a different
> language?

Fortran and C++ have standard mechanisms for C interoperability.  I 
don't know about Pascal, I haven't used it since the 80s...

>> Other languages know how to call C (so they can access the platform's
>> services).
>
> The platform interface should be language-independent. This is where a
> binary interface becomes useful. (C has done a good job here in past, in
> defining such interfaces, but there is often confusion; is 'long' 32-bits or
> 64-bits for example? gcc for Windows says 32, gcc for Linux says 64.)

The sizes of types is defined by the platform's ABI.  When in Rome and 
all that..

> But should a complex, register-based interface (I believe this might be for
> x86-64) be also used as the standard when one C function calls another C
> function in the same application?

Why not?  The AMD64 calling convention offers significant performance 
advantages.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13959

On 27.11.2011 00:35, BartC wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:9jda3mF4d0U13@mid.individual.net...
>> On 11/27/11 12:00 PM, BartC wrote:
>>> "Markus Wichmann"<nullplan@gmx.net>  wrote:
>>>
>>>> Plus, when you ask a compiler writer whether he want's to include
>>>> _two_different_ calling conventions in his compiler with the added
>>>> maintenance and stuff, guess what he'll say.
>>>
>>> Isn't that what happens anyway, when calling a function in a different
>>> language? (pascal, stdcall and so on.)
>>
>> No.  At least not on any of the platforms I'm familiar with.
> 
> So how do you call Pascal, Fortran, (or C++) etc from C on your platform? Do
> you not need to tell it that that imported function is in a different
> language?
> 

Not here. Well, there's two possibilities: For one, my C compiler has a
nonstandard way of declaring a function with another calling convention,
for two my Pascal compiler has a de-facto standard way (i.e. Borland
does it the same way. ISO Pascal is next to unusable) of declaring a
function with another calling convention. OK, that is, my Pascal
compiler_s_. For Freepascal, I can either append "cdecl;" to a function
declaration/definition, or compile it with the commandline switch
"-Cccdecl", which I can also set in the config file, and for GNU Pascal,
cdecl is already the standard.

>> Other languages know how to call C (so they can access the platform's
>> services).
> 
> The platform interface should be language-independent. This is where a
> binary interface becomes useful. (C has done a good job here in past, in 
> defining such interfaces, but there is often confusion; is 'long' 32-bits or 
> 64-bits for example? gcc for Windows says 32, gcc for Linux says 64.)
> 

The binary interface is necessary when multiple compilers come into
play. Those may even be two C compilers, or a C compiler and an
assembler. (As is needed for writing a C standard library, because most
OSes cannot call a C-style main function, so you need a wrapper to get
from the OS-specific entry point to main(). You also need assembly for
other stuff in there.)

Also (I cannot resist):

$ uname -m -o
x86_64 GNU/Linux
$ cat test.c
#include <stdio.h>

int main()
{
    printf("%d\n", sizeof(long));
    return 0;
}
$ gcc test.c && ./a.out
8
$ gcc -m32 test.c && ./a.out
4

The ABI also defines much of the stuff the C standard deliberately
excludes, like padding rules of structures (arrays in structures are
only padded as much as the array type is big, i.e. a "char a[3];"
receives no padding at all on AMD64/SysV)

> But should a complex, register-based interface (I believe this might be for
> x86-64) be also used as the standard when one C function calls another C
> function in the same application?
> 

The register-based interface of AMD64 is really not that much harder to
use than the register preservance rules of i386 were. You know, when a
function could only use three registers before having to set up a stack
frame. With AMD64 you could reserve the whole first register bank to
parameter passing and still have 8 registers left to do all of your
calculations. The result is that the calculations stay in the processor
without having to use the memory, which is nowadays a severe speedup.

CYA,
Markus

[toc] | [prev] | [next] | [standalone]

#14016

Markus Wichmann <nullplan@gmx.net> writes:
[...]
> $ uname -m -o
> x86_64 GNU/Linux
> $ cat test.c
> #include <stdio.h>
>
> int main()
> {
>     printf("%d\n", sizeof(long));
>     return 0;
> }
> $ gcc test.c && ./a.out
> 8
> $ gcc -m32 test.c && ./a.out
> 4
[...]

That could have failed, since "%d" expects an int argument but you
passed it a size_t.

    printf("%d\n", (int)sizeof(long));

(And "int main()" should be "int main(void)".)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#14085

On 29.11.2011 01:17, Keith Thompson wrote:
> Markus Wichmann <nullplan@gmx.net> writes:
> [...]
>> $ uname -m -o
>> x86_64 GNU/Linux
>> $ cat test.c
>> #include <stdio.h>
>>
>> int main()
>> {
>>     printf("%d\n", sizeof(long));
>>     return 0;
>> }
>> $ gcc test.c && ./a.out
>> 8
>> $ gcc -m32 test.c && ./a.out
>> 4
> [...]
> 
> That could have failed, since "%d" expects an int argument but you
> passed it a size_t.
> 

Oh, my bad. "%zd" it is, then. Unless, of course, I'm compiling with
MinGW or MSVC, then it is "%d" with a cast. Or "%ld", it doesn't matter,
I'd need to cast anyway. (Both MinGW and MSVC use the outdated
msvcrt.dll and crtdll.dll, both of which don't provide a C99 compatible
printf(). Microsoft officially stated to stop caring about their C
compiler and library in 1998. Ah, portability is but a dream!)

>     printf("%d\n", (int)sizeof(long));
> 
> (And "int main()" should be "int main(void)".)
> 

OK, that's just a nitpick. The semantic difference between both of them
is that in the first case, the compiler doesn't complain if the caller
of main() passes additional arguments. In both cases the compiler
doesn't even get to see the caller, the only one who does that is the
linker.

CYA,
Markus

[toc] | [prev] | [next] | [standalone]

#14088

Markus Wichmann <nullplan@gmx.net> writes:
> On 29.11.2011 01:17, Keith Thompson wrote:
>> Markus Wichmann <nullplan@gmx.net> writes:
>> [...]
>>> $ uname -m -o
>>> x86_64 GNU/Linux
>>> $ cat test.c
>>> #include <stdio.h>
>>>
>>> int main()
>>> {
>>>     printf("%d\n", sizeof(long));
>>>     return 0;
>>> }
>>> $ gcc test.c && ./a.out
>>> 8
>>> $ gcc -m32 test.c && ./a.out
>>> 4
>> [...]
>> 
>> That could have failed, since "%d" expects an int argument but you
>> passed it a size_t.
>> 
>
> Oh, my bad. "%zd" it is, then.

No, "%zu", since size_t is an unsigned type.

[...]
>> (And "int main()" should be "int main(void)".)
>
> OK, that's just a nitpick. The semantic difference between both of them
> is that in the first case, the compiler doesn't complain if the caller
> of main() passes additional arguments. In both cases the compiler
> doesn't even get to see the caller, the only one who does that is the
> linker.

I've argued that a program using "int main()", as opposed to "int
main(void)", has undefined behavior, since "int main()" is not one of
the forms permitted by C99 5.1.2.2.1 (nor is it quite equivalent to
either of them).

And it's legal to call main recursively.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16192

Keith Thompson <kst-u@mib.org> writes:

> Markus Wichmann <nullplan@gmx.net> writes:
>> On 29.11.2011 01:17, Keith Thompson wrote:
>>> Markus Wichmann <nullplan@gmx.net> writes:
>>> [...]
>>>> $ uname -m -o
>>>> x86_64 GNU/Linux
>>>> $ cat test.c
>>>> #include <stdio.h>
>>>>
>>>> int main()
>>>> {
>>>>     printf("%d\n", sizeof(long));
>>>>     return 0;
>>>> }
>>>> $ gcc test.c && ./a.out
>>>> 8
>>>> $ gcc -m32 test.c && ./a.out
>>>> 4
>>> [...]
>>> 
>>> That could have failed, since "%d" expects an int argument but you
>>> passed it a size_t.
>>> 
>>
>> Oh, my bad. "%zd" it is, then.
>
> No, "%zu", since size_t is an unsigned type.
>
> [...]
>>> (And "int main()" should be "int main(void)".)
>>
>> OK, that's just a nitpick. The semantic difference between both of them
>> is that in the first case, the compiler doesn't complain if the caller
>> of main() passes additional arguments. In both cases the compiler
>> doesn't even get to see the caller, the only one who does that is the
>> linker.
>
> I've argued that a program using "int main()", as opposed to "int
> main(void)", has undefined behavior, since "int main()" is not one of
> the forms permitted by C99 5.1.2.2.1 (nor is it quite equivalent to
> either of them).  [snip]

It is equivalent in the sense that the Standard uses the
term.  Obviously so, since otherwise every single K&R-era
program that had 'int main(){ ... }' would have undefined
behavior under ANSI/ISO C;  surely that point was considered
by the standard committee.

[toc] | [prev] | [next] | [standalone]

#16223

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> I've argued that a program using "int main()", as opposed to "int
>> main(void)", has undefined behavior, since "int main()" is not one of
>> the forms permitted by C99 5.1.2.2.1 (nor is it quite equivalent to
>> either of them).  [snip]
>
> It is equivalent in the sense that the Standard uses the
> term.  Obviously so, since otherwise every single K&R-era
> program that had 'int main(){ ... }' would have undefined
> behavior under ANSI/ISO C;  surely that point was considered
> by the standard committee.

I'm uncomfortable with conclusions reached by first assuming that the
standard doesn't break pre-ANSI code, and interpreting the wording based
on that assumption.

I can accept, based on your argument, that "int main()" is *intended* to
be valid.  I don't agree that the current wording in the standard
actually *says* that it's valid.  The only basis for assuming that
"equivalent" has the meaning you say it does is that Bad Things Happen
if it doesn't.

Someone reading the current ISO C standard with no knowledge of pre-ANSI
C would have no basis to assume that "int main()" is valid.

These two programs differ only in how they define main, and they clearly
are not equivalent; the first violates a constraint, while the second
does not.

int main(void) {
    if (0) return main(42);
}

int main() {
    if (0) return main(42);
}

I believe this was an oversight by the authors of the standard (one that
isn't corrected in C11, unless they did something after N1570).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16545

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
> [...]
>>> I've argued that a program using "int main()", as opposed to "int
>>> main(void)", has undefined behavior, since "int main()" is not one of
>>> the forms permitted by C99 5.1.2.2.1 (nor is it quite equivalent to
>>> either of them).  [snip]
>>
>> It is equivalent in the sense that the Standard uses the
>> term.  Obviously so, since otherwise every single K&R-era
>> program that had 'int main(){ ... }' would have undefined
>> behavior under ANSI/ISO C;  surely that point was considered
>> by the standard committee.
>
> I'm uncomfortable with conclusions reached by first assuming that the
> standard doesn't break pre-ANSI code, and interpreting the wording based
> on that assumption.

For me it depends on what the motivation is for forming those
conclusions.  For purposes of deciding what "the general public"
ought to think about C, I think it's perfectly okay to use that
kind of reasoning.  For purposes of revising and improving wording
in the Standard, I'm more inclined to reason along the lines you
are advocating.  But it depends on the circumstances, because those
situations are different in some important ways.

> I can accept, based on your argument, that "int main()" is *intended* to
> be valid.  I don't agree that the current wording in the standard
> actually *says* that it's valid.  The only basis for assuming that
> "equivalent" has the meaning you say it does is that Bad Things Happen
> if it doesn't.
>
> Someone reading the current ISO C standard with no knowledge of pre-ANSI
> C would have no basis to assume that "int main()" is valid.
>
> These two programs differ only in how they define main, and they clearly
> are not equivalent; the first violates a constraint, while the second
> does not.
>
> int main(void) {
>     if (0) return main(42);
> }
>
> int main() {
>     if (0) return main(42);
> }
>
> I believe this was an oversight by the authors of the standard (one that
> isn't corrected in C11, unless they did something after N1570).

I don't think we really have any significant disagreement.  I
believe the intent was that the two forms be interchangeable as
far as invokability goes, and you can accept that.  You think the
existing wording need clarifying, and I can go along with that
(and if it were up to me I would simply add a footnote with the
clarification).  Beyond that, I don't think it's fruitful to be
concerned about what the Standard "really says", because the
current wording includes an English word which is ambiguous in
its meaning.

[toc] | [prev] | [next] | [standalone]

#13936

On 11/27/11 12:30 PM, Stefan Ram wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> No.  At least not on any of the platforms I'm familiar with.  Other
>> languages know how to call C (so they can access the platform's services).
>
>    In this case, wouldn't »know how to call the platform's ABI«
>    a more appropriate wording than »know how to call C«?

The two tend to be synonymous.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13961

Markus Wichmann <nullplan@gmx.net> wrote:
> On 26.11.2011 12:07, BartC wrote:
> 
> > Surely compiler writers can do what they like - within their own 
> > implementation? Calling conventions are only important when calling foreign 
> > and OS functions, and being called from outside.
> > 
> 
> Yeah, that's right!
> 
> Only... every function not defined "static" may be called "from the
> outside". Every call to a function only declared (and not qualified
> "static") but not defined may be to a foreign function.
> 

Plus, when a "static" function pointer is passed around, either the
function must get the standard calling convention or a stub must be
written.

Or, an implementation that wants a non-standard calling convention may
use a non-standard keyword to differentiate internal functions that
must be called with the new calling convention from exported functions.

-- 
André Gillibert

[toc] | [prev] | [next] | [standalone]

#15941

On Sun, 27 Nov 2011 11:20:31 +0100, André Gillibert
<MetaEntropy.removeThis@gmail.com> wrote:

> Markus Wichmann <nullplan@gmx.net> wrote:
> > On 26.11.2011 12:07, BartC wrote:
> > 
> > > Surely compiler writers can do what they like - within their own 
> > > implementation? Calling conventions are only important when calling foreign 
> > > and OS functions, and being called from outside.
> > > 
> > 
> > Yeah, that's right!
> > 
> > Only... every function not defined "static" may be called "from the
> > outside". Every call to a function only declared (and not qualified
> > "static") but not defined may be to a foreign function.
> > 
> 
> Plus, when a "static" function pointer is passed around, either the
> function must get the standard calling convention or a stub must be
> written.
> 
Or the function pointers are nonstandardly implementation-dependently
qualified (which I've seen). Or you use fat pointers that contain the
convention (which I've not seen, but it would be conforming).

> Or, an implementation that wants a non-standard calling convention may
> use a non-standard keyword to differentiate internal functions that
> must be called with the new calling convention from exported functions.

keyword or pragma or config setting, or possibly something else. Or
the compiler can guess -- for example, any 'static' function whose
address is never directly exported nor stored anywhere that could be
exported can safely be 'optimized'. That's a simple rule that suffices
for probably most useful cases.

[toc] | [prev] | [next] | [standalone]

#14002

On 2011-11-26, BartC <bc@freeuk.com> wrote:
> "Seebs" <usenet-nospam@seebs.net> wrote in message 
>> But you don't always get a vote -- the ABI may have specified the rules
>> for you.  And in fact, often has.

> Surely compiler writers can do what they like - within their own 
> implementation? Calling conventions are only important when calling foreign 
> and OS functions, and being called from outside.

The thing is, if you are producing functions with external linkage, you had
BETTER be writing them in the ABI-standard way, because your users are going
to expect to be able to call those functions from other stuff -- other
compilers, other languages, etcetera.

A whole lot of C functions end up with external linkage, at which point it
is almost always the case that Bad Things will happen if they don't comply
with the ABI.  (In particular:  Even if a given function is definitely never
called by anything but your compiler's output, it has to have the same calling
sequence as other functions with the same prototype, some of which will
probably be in a library that is called from another language or the output
of another compiler.)

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web