Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #94083 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-09-26 14:31 +0100 |
| Last post | 2016-10-15 13:46 -0700 |
| Articles | 20 on this page of 154 — 22 participants |
Back to article view | Back to comp.lang.c
Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 14:31 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 15:45 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 15:22 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 16:31 +0200
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-27 15:05 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-28 00:42 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 09:50 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-28 18:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 12:28 +0100
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 04:36 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 05:31 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 14:00 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 07:48 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 17:36 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 10:38 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 19:47 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 12:25 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 12:26 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 13:10 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 13:22 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 14:13 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 01:15 +0100
Re: Why I use gcc James Harris <james.harris.1@gmail.com> - 2016-10-08 10:42 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 11:36 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 14:25 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 15:05 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 16:29 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 17:21 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 16:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 16:58 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 21:15 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-08 11:27 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 20:09 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 21:16 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 21:28 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 01:19 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 01:36 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-08 09:32 -0700
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-09 03:44 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 12:07 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 12:12 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 12:37 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 13:57 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 14:32 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 20:00 +0100
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-09 13:14 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 22:54 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-15 14:40 -0700
Re: Why I use gcc James Kuyper <jameskuyper@verizon.net> - 2016-10-07 10:37 -0400
Re: Why I use gcc supercat@casperkitty.com - 2016-10-07 07:52 -0700
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-07 09:10 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-07 10:48 -0700
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-07 16:21 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-08 11:15 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 17:12 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 12:20 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 12:32 -0700
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 14:45 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 15:12 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 15:26 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-09-26 08:00 -0700
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:49 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 17:30 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 21:12 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 22:09 +0200
Re: Why I use gcc supercat@casperkitty.com - 2016-09-26 13:32 -0700
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 23:14 +0200
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 22:47 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:13 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-27 01:18 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-26 17:41 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 02:01 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:41 -0700
Re: Why I use gcc James Harris <james.harris.1@gmail.com> - 2016-09-27 01:41 +0100
Re: Why I use gcc jameskuyper@verizon.net - 2016-09-26 18:15 -0700
Re: Why I use gcc Gareth Owen <gwowen@gmail.com> - 2016-09-27 20:59 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-27 21:50 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 06:26 -0700
Re: Why I use gcc gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-27 23:23 +0000
Re: Why I use gcc Noob <root@127.0.0.1> - 2016-10-08 00:12 +0200
Re: Why I use gcc James Kuyper <jameskuyper@verizon.net> - 2016-10-07 23:11 -0400
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 10:58 +0100
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-08 07:07 -0700
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 21:44 -0700
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 09:48 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 11:22 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 13:52 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 14:47 +0200
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 15:18 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 14:38 +0100
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 17:21 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 17:17 +0200
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:52 -0700
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-09-30 02:00 -0500
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 07:18 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:46 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 09:11 -0700
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 13:33 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 14:13 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 15:30 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 08:29 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 07:11 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 21:43 +0100
Re: Why I use gcc raltbos@xs4all.nl (Richard Bos) - 2016-09-30 17:50 +0000
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:04 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-26 17:39 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:49 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 11:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 11:56 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-27 15:15 -0700
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-28 08:55 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 22:11 +0200
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 22:04 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 11:39 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-10 07:32 -0700
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-10-10 16:17 +0100
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-10-10 21:09 -0500
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-10-11 04:18 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 10:56 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 04:08 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 13:36 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 06:20 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 14:29 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-11 09:31 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 19:38 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-11 12:23 -0700
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-11 23:19 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 23:26 +0100
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-12 09:01 +0200
Re: Why I use gcc supercat@casperkitty.com - 2016-10-12 08:55 -0700
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-12 10:52 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-12 12:34 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-12 13:18 -0700
Re: Why I use gcc luser droog <luser.droog@gmail.com> - 2016-10-12 13:24 -0700
Re: Why I use gcc crankypuss <undisclosedUserid@gmail.com> - 2016-10-13 13:31 -0600
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 03:00 -0700
Re: Why I use gcc crankypuss <undisclosedUserid@gmail.com> - 2016-10-16 04:46 -0600
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 04:05 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-11 12:28 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-11 13:24 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 21:28 +0100
Re: Why I use gcc gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-11 20:43 +0000
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-10-11 23:40 -0500
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 04:40 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 18:19 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-10 09:08 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 18:04 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-10 10:39 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-10 11:25 -0700
Re: Why I use gcc Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-10 17:05 -0400
Re: Why I use gcc supercat@casperkitty.com - 2016-10-10 14:46 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-15 13:39 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-15 13:40 -0700
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-15 13:46 -0700
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-10-07 23:11 -0400 |
| Message-ID | <nt9o4g$1lh$1@dont-email.me> |
| In reply to | #94574 |
On 10/07/2016 06:12 PM, Noob wrote: > On 27/09/2016 21:59, Gareth Owen wrote: ... >> c.l.c. predates charters. > > Doesn't mean anyone can post anything about toolchains, assembly code, > linkers, optimization levels, debugging tools, IDEs, etc. True - but this is an unmoderated group, which means you can in fact post any of those things. You shouldn't, but you can.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-08 10:58 +0100 |
| Message-ID | <ntafvs$6gc$1@dont-email.me> |
| In reply to | #94582 |
On 08/10/2016 04:11, James Kuyper wrote: > On 10/07/2016 06:12 PM, Noob wrote: >> On 27/09/2016 21:59, Gareth Owen wrote: > ... >>> c.l.c. predates charters. >> >> Doesn't mean anyone can post anything about toolchains, assembly code, >> linkers, optimization levels, debugging tools, IDEs, etc. > > True - but this is an unmoderated group, which means you can in fact > post any of those things. You shouldn't, but you can. But posts about Jesus are completely topical of course! Example: On 08/10/2016 04:47, James Kuyper wrote: > it's > entirely possible that Jesus taught things that have implications that > apply to computer programming People had better not post anything about writing practical C code however in case if there is the slightest possibility of having to mention an actual compiler by name. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-10-08 07:07 -0700 |
| Message-ID | <f777b7a9-86d4-4e19-98fe-f0b6a36a6eb8@googlegroups.com> |
| In reply to | #94590 |
On Saturday, October 8, 2016 at 5:58:45 AM UTC-4, Bart wrote: > On 08/10/2016 04:11, James Kuyper wrote: > > On 10/07/2016 06:12 PM, Noob wrote: > >> On 27/09/2016 21:59, Gareth Owen wrote: > > ... > >>> c.l.c. predates charters. > >> > >> Doesn't mean anyone can post anything about toolchains, assembly code, > >> linkers, optimization levels, debugging tools, IDEs, etc. > > > > True - but this is an unmoderated group, which means you can in fact > > post any of those things. You shouldn't, but you can. > > But posts about Jesus are completely topical of course! Example: No, they are not. But, since this is unmoderated group, they can still be posted. > On 08/10/2016 04:47, James Kuyper wrote: > > > it's > > entirely possible that Jesus taught things that have implications that > > apply to computer programming That wasn't a message about Jesus, it was about the topicality of messages about Jesus. Topicality (at least, topicality for c.l.c) is always on-topic. > People had better not post anything about writing practical C code > however in case if there is the slightest possibility of having to > mention an actual compiler by name. It doesn't matter whether you name the compiler; if your code relies upon implementation-specific behavior, it's better to discuss that behavior in a forum devoted to implementations which actually provide that behavior. However, since this is unmoderated group, you're perfectly free to waste your time and ours by posting such messages here, where there's likely to to be both less interest and less relevant expertise.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-07 21:44 -0700 |
| Message-ID | <953945ba-c554-4ef2-9bd4-69e06900637e@googlegroups.com> |
| In reply to | #94574 |
On Friday, October 7, 2016 at 11:12:41 PM UTC+1, Noob wrote: > > > c.l.c. predates charters. > > Doesn't mean anyone can post anything about toolchains, assembly code, > linkers, optimization levels, debugging tools, IDEs, etc. > There are non-topical posts (post about knitting). Then there are C- related but not quite topical posts. Then there are threads that maybe start with something topical like function flow graphs, turn into the mathematics of knots, and then end up as discussion of knitting. That's accepted in a way that a post that started off on knitting would not be.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-27 09:48 +0200 |
| Message-ID | <nsd885$pdm$1@dont-email.me> |
| In reply to | #94106 |
On 26/09/16 22:32, supercat@casperkitty.com wrote: > On Monday, September 26, 2016 at 2:13:07 PM UTC-5, David Brown wrote: >> The root of the problem is not the compilers or the C standards - it is >> MS and Windows, which is a jumbled and inconsistent mess of interfaces >> and calling conventions, and which never had a proper defined ABI that >> everyone could stick to. Thus everything involving external functions >> and Windows libraries is compiler specific, and there are no standard >> headers or common libraries. > > There are hardware platforms where different calling conventions may be > more efficient under different circumstances, and where being able to > specify which calling conventions should be used in what circumstances > may improve execution efficiency (e.g. in some cases calling convention X > may be more efficient than Y for leaf functions, but Y may be more > efficient than X for functions which need to call other functions). > > Should compiler writers not give programmers the opportunity to improve the > efficiency of their code by letting them tell the compiler which calling > conventions to use in different cases? > No, that's fair enough (though it is better if the toolchain can figure out the more efficient calling conventions itself). And even when the standard convention for a target is efficient, you might have special requirements for particular uses (naked functions, interrupt functions, etc.). For low-level code, that's no problem. The problem here is that you have a single OS on a single hardware platform, with application level code - and you /still/ have a dozen different calling conventions to deal with, with each compiler having different details in how these are specified.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-27 11:22 +0100 |
| Message-ID | <nsdh8f$m60$1@dont-email.me> |
| In reply to | #94124 |
On 27/09/2016 08:48, David Brown wrote: > On 26/09/16 22:32, supercat@casperkitty.com wrote: >> Should compiler writers not give programmers the opportunity to improve the >> efficiency of their code by letting them tell the compiler which calling >> conventions to use in different cases? > The problem here is that you have a single OS on a single hardware > platform, with application level code - and you /still/ have a dozen > different calling conventions to deal with, with each compiler having > different details in how these are specified. > Why doesn't the language acknowledge the existence of foreign functions? That is, that there might be other languages that do things differently, but a C program might want to call functions in that other language, and vice versa. This could be one reason why there are several different conventions even on the same target. (On x64, I use my own convention different from both the Win64 and Linux64 ABI. Within the language I use foreign function attributes such as 'windows' and 'clang'.) C seems to assume that a C program will only ever call a C function. Yet, '__stdcall' has become a de facto attribute amongst some compilers, although they can't seem to agree on its placement. If the language gave some guidelines on this, perhaps there wouldn't be such disagreement. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-27 13:52 +0200 |
| Message-ID | <nsdmh0$7ip$1@dont-email.me> |
| In reply to | #94126 |
On 27/09/16 12:22, BartC wrote: > On 27/09/2016 08:48, David Brown wrote: >> On 26/09/16 22:32, supercat@casperkitty.com wrote: > >>> Should compiler writers not give programmers the opportunity to >>> improve the >>> efficiency of their code by letting them tell the compiler which calling >>> conventions to use in different cases? > >> The problem here is that you have a single OS on a single hardware >> platform, with application level code - and you /still/ have a dozen >> different calling conventions to deal with, with each compiler having >> different details in how these are specified. >> > > Why doesn't the language acknowledge the existence of foreign functions? > > That is, that there might be other languages that do things differently, > but a C program might want to call functions in that other language, and > vice versa. > > This could be one reason why there are several different conventions > even on the same target. (On x64, I use my own convention different from > both the Win64 and Linux64 ABI. Within the language I use foreign > function attributes such as 'windows' and 'clang'.) > > C seems to assume that a C program will only ever call a C function. The C language standards only discuss C - they don't deal with calling other functions because that would be outside the scope of C. But implementations usually have some convenient way to call external functions. On most systems, external functions and C compilers use the same standardised ABI, thus nothing special is needed for calling external functions. On Windows, the ABI is not standardised either for the external functions, or for compilers, so you need a range of compiler-specific extensions for external interfacing. > > Yet, '__stdcall' has become a de facto attribute amongst some compilers, > although they can't seem to agree on its placement. If the language gave > some guidelines on this, perhaps there wouldn't be such > disagreement. > That is not something that is covered in the C standards, and I don't think it is something that should be covered there.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-09-27 14:47 +0200 |
| Message-ID | <nsdpok$htr$1@dont-email.me> |
| In reply to | #94129 |
Le 27/09/2016 à 13:52, David Brown a écrit : > But implementations usually have some convenient way to call external > functions. On most systems, external functions and C compilers use the > same standardised ABI, thus nothing special is needed for calling > external functions. On Windows, the ABI is not standardised either for > the external functions, or for compilers, so you need a range of > compiler-specific extensions for external interfacing. You are showing your own ignorance. Please read the documents for the windows ABI before you go on.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-27 15:18 +0200 |
| Message-ID | <nsdrjg$p7f$1@dont-email.me> |
| In reply to | #94131 |
On 27/09/16 14:47, jacobnavia wrote: > Le 27/09/2016 à 13:52, David Brown a écrit : >> But implementations usually have some convenient way to call external >> functions. On most systems, external functions and C compilers use the >> same standardised ABI, thus nothing special is needed for calling >> external functions. On Windows, the ABI is not standardised either for >> the external functions, or for compilers, so you need a range of >> compiler-specific extensions for external interfacing. > > You are showing your own ignorance. > > Please read the documents for the windows ABI before you go on. Windows uses __cdecl, __stdcall, and __fastcall calling conventions. The Win32 API uses __stdcall normally, but other libraries can use different conventions. Callbacks can use other choices. Most 32-bit compilers on Windows use __cdecl calling convention by default - but some use different ones. I believe that for 64-bit Windows API, there is a single calling convention (which is different from the one used on all other x86-64 systems, but at least it is consistent on Windows).
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-27 14:38 +0100 |
| Message-ID | <nsdsns$t9i$1@dont-email.me> |
| In reply to | #94134 |
On 27/09/2016 14:18, David Brown wrote: > On 27/09/16 14:47, jacobnavia wrote: >> Le 27/09/2016 à 13:52, David Brown a écrit : >>> But implementations usually have some convenient way to call external >>> functions. On most systems, external functions and C compilers use the >>> same standardised ABI, thus nothing special is needed for calling >>> external functions. On Windows, the ABI is not standardised either for >>> the external functions, or for compilers, so you need a range of >>> compiler-specific extensions for external interfacing. >> >> You are showing your own ignorance. >> >> Please read the documents for the windows ABI before you go on. > > Windows uses __cdecl, __stdcall, and __fastcall calling conventions. > The Win32 API uses __stdcall normally, but other libraries can use > different conventions. Callbacks can use other choices. Most 32-bit > compilers on Windows use __cdecl calling convention by default - but > some use different ones. With Windows 32-bit, I've only come across what I call 'C' and 'Windows' conventions. I think the C one required the caller to adjust the stack, but with 'Windows' it was done for you. I don't think 16-bit was that different. With callbacks (from Windows to application for example) then I think the callback function had to use the same convention as the caller. And worry about which registers to preserve. > I believe that for 64-bit Windows API, there is a single calling > convention (which is different from the one used on all other x86-64 > systems, but at least it is consistent on Windows). Yes, there's one instead of two. And extra rules to do with stack alignment. However, on Windows 64 __stdcall disappears, but there appears to be a need to use __declspec(dllimport) in some contexts. I can't remember why that was needed or what problem it solved. I haven't used Linux enough to know if there are a mix of conventions or not, or whether every single language (the ones that aren't just part of the gcc suite) has always used exactly the same convention as every other language. (I'm sure that C++ calling C needs to do something special in the source code to make it possible.) In my case with my own languages I've had to be able to communicate with C libraries, and the Windows API, and to provide callbacks. I just do whatever is necessary. Internally, they might use their own conventions. But having to specify a call convention isn't really the problem (compared to /using/ Win32, sticking a __stdcall somewhere should be the easy bit!). It's just that compilers seem to use several incompatible ways of doing so. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-09-27 17:21 +0200 |
| Message-ID | <nse2oq$k1d$2@dont-email.me> |
| In reply to | #94137 |
Le 27/09/2016 à 15:38, BartC a écrit : > With Windows 32-bit, I've only come across what I call 'C' and 'Windows' > conventions. I think the C one required the caller to adjust the stack, > but with 'Windows' it was done for you. Yes, the first one is the _cdecl and the second is _stdcall. The _stdcall convention was called "Pascal" under windows 16 bits. I don't think 16-bit was that > different. Yes they were the same. > > With callbacks (from Windows to application for example) then I think > the callback function had to use the same convention as the caller. And > worry about which registers to preserve. No, the registers to be preserved are always the same in all calling conventions and there were never any registers to preserve, etc that were visible to the programmer. All compilers handle the registers automatically.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-09-27 17:17 +0200 |
| Message-ID | <nse2hq$k1d$1@dont-email.me> |
| In reply to | #94134 |
Le 27/09/2016 à 15:18, David Brown a écrit : > Windows uses __cdecl, __stdcall, and __fastcall calling conventions. No. The windows ABI uses (under 32 bits) exclusively the _stdcall calling convention. You are confusing Windows with the many compilers running under windows, that offer some special calling conventions line _fastcall for speed. Note that those special calling conventions are INCOMPATIBLE with Windows and can't be used for any call to the windows API. The _cdecl calling convention doesn't exist, of course. It is just plain C DECLarations, i.e. normal C. Windows 64 bits uses 4 registers for the first 4 arguments of a call. The details are in the ABI. There are no other calling conventions under windows 64 bits.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-27 08:52 -0700 |
| Message-ID | <ln1t05tk5e.fsf@kst-u.example.com> |
| In reply to | #94146 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> The _cdecl calling convention doesn't exist, of course. It is just plain
> C DECLarations, i.e. normal C.
[...]
You say it doesn't exist, then you explain what it is? BTW it's
"__cdecl", not "_cdecl" (though I wouldn't be surprised if both
forms are accepted).
https://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
__cdecl
Visual Studio 2015
Microsoft Specific
__cdecl is the default calling convention for C and C++
programs. Because the stack is cleaned up by the caller, it can
do vararg functions. The __cdecl calling convention creates
larger executables than __stdcall, because it requires each
function call to include stack cleanup code. The following list
shows the implementation of this calling convention.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-09-30 02:00 -0500 |
| Message-ID | <u93sub5ul7lm162guqb5jdhsspai8f79ej@4ax.com> |
| In reply to | #94146 |
On Tue, 27 Sep 2016 17:17:24 +0200, jacobnavia <jacob@jacob.remcomp.fr> wrote: >Le 27/09/2016 à 15:18, David Brown a écrit : >> Windows uses __cdecl, __stdcall, and __fastcall calling conventions. > >No. > >The windows ABI uses (under 32 bits) exclusively the _stdcall calling >convention. > >You are confusing Windows with the many compilers running under windows, >that offer some special calling conventions line _fastcall for speed. >Note that those special calling conventions are INCOMPATIBLE with >Windows and can't be used for any call to the windows API. > >The _cdecl calling convention doesn't exist, of course. It is just plain >C DECLarations, i.e. normal C. > >Windows 64 bits uses 4 registers for the first 4 arguments of a call. >The details are in the ABI. There are no other calling conventions under >windows 64 bits. While minor, there are a few Win32 functions like wsprintf(), which use __cdecl.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-27 07:18 -0700 |
| Message-ID | <02d08d50-7b34-415c-b482-2346c0bb79d8@googlegroups.com> |
| In reply to | #94129 |
On Tuesday, September 27, 2016 at 6:52:19 AM UTC-5, David Brown wrote:
> The C language standards only discuss C - they don't deal with calling
> other functions because that would be outside the scope of C.
The question of how to call functions written in language X from language
Y generally has at least as much to do with language Y as language X.
If the Standard had specified that quality implementations for platforms
that support languages or calling conventions X, Y, and Z should when
practical support a particular syntax like
__stdc_convention(conventionName,(options)) foo(params);
__stdc_convention(conventionName,(options)) (*funcptr)(params);
where conventionName is one of the items on an Implementation-Defined
list, that would have avoided a lot of needless incompatibilities (note
that conforming platforms would not be required to support any outside
languages or calling conventions, and implementations that don't support
any would not be required to support the above syntax).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-27 08:46 -0700 |
| Message-ID | <ln60phtkfh.fsf@kst-u.example.com> |
| In reply to | #94129 |
David Brown <david.brown@hesbynett.no> writes:
> On 27/09/16 12:22, BartC wrote:
[...]
>> Why doesn't the language acknowledge the existence of foreign functions?
>>
>> That is, that there might be other languages that do things differently,
>> but a C program might want to call functions in that other language, and
>> vice versa.
>>
>> This could be one reason why there are several different conventions
>> even on the same target. (On x64, I use my own convention different from
>> both the Win64 and Linux64 ABI. Within the language I use foreign
>> function attributes such as 'windows' and 'clang'.)
>>
>> C seems to assume that a C program will only ever call a C function.
>
> The C language standards only discuss C - they don't deal with calling
> other functions because that would be outside the scope of C.
That's not inherently necessary. A number of other language
standards (C++, Ada) *do* provide facilities for calling code in
other languages.
I think the reasons the C standard doesn't do so are historical.
Such features could have been added by one of the C standards,
but they weren't -- perhaps because compilers already had their
own mechanisms and it wasn't practical to reconcile them. It was
a missed opportunity.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-27 09:11 -0700 |
| Message-ID | <462ade3c-05bc-41a3-b8d4-73f865096c66@googlegroups.com> |
| In reply to | #94151 |
On Tuesday, September 27, 2016 at 10:46:29 AM UTC-5, Keith Thompson wrote: > I think the reasons the C standard doesn't do so are historical. > Such features could have been added by one of the C standards, > but they weren't -- perhaps because compilers already had their > own mechanisms and it wasn't practical to reconcile them. It was > a missed opportunity. In cases where a feature was implemented in divergent fashion, the authors of the Standard have generally been loath to say much about it, perhaps out of a desire to avoid any perception of favoritism, or out of a fear that the language will become "fragmented" if they acknowledge that different implementations *should* have different features.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-27 13:33 +0100 |
| Message-ID | <878tudcyj5.fsf@bsb.me.uk> |
| In reply to | #94126 |
BartC <bc@freeuk.com> writes: > On 27/09/2016 08:48, David Brown wrote: >> On 26/09/16 22:32, supercat@casperkitty.com wrote: > >>> Should compiler writers not give programmers the opportunity to improve the >>> efficiency of their code by letting them tell the compiler which calling >>> conventions to use in different cases? > >> The problem here is that you have a single OS on a single hardware >> platform, with application level code - and you /still/ have a dozen >> different calling conventions to deal with, with each compiler having >> different details in how these are specified. > > Why doesn't the language acknowledge the existence of foreign > functions? > > That is, that there might be other languages that do things > differently, but a C program might want to call functions in that > other language, and vice versa. It does. The standard provides ways for implementations to call almost any sort of function. You might have extern __haskell fib(...); for example, or any of a thousand other possibilities. If you mean why did the ISO committee not standardise any of these, I suspect you know the answer. I want to call into Haskell lazy functions, Ada rendezvous, SR remove procedures and static C++ method functions. What's your list? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-27 14:13 +0100 |
| Message-ID | <nsdr8s$o1o$1@dont-email.me> |
| In reply to | #94130 |
On 27/09/2016 13:33, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 27/09/2016 08:48, David Brown wrote: >>> On 26/09/16 22:32, supercat@casperkitty.com wrote: >> >>>> Should compiler writers not give programmers the opportunity to improve the >>>> efficiency of their code by letting them tell the compiler which calling >>>> conventions to use in different cases? >> >>> The problem here is that you have a single OS on a single hardware >>> platform, with application level code - and you /still/ have a dozen >>> different calling conventions to deal with, with each compiler having >>> different details in how these are specified. >> >> Why doesn't the language acknowledge the existence of foreign >> functions? >> >> That is, that there might be other languages that do things >> differently, but a C program might want to call functions in that >> other language, and vice versa. > > It does. The standard provides ways for implementations to call almost > any sort of function. You might have > > extern __haskell fib(...); > > for example, or any of a thousand other possibilities. > If you mean why did the ISO committee not standardise any of these, I > suspect you know the answer. I want to call into Haskell lazy > functions, Ada rendezvous, SR remove procedures and static C++ method > functions. What's your list? I'm not concerned with the details, only that an attribute /like/ __haskell or __stdcall might exist. In that case, where should it go? For example: __haskell int* fib(); int* __haskell fib(); int __haskell * fib(); Any compilers that know about '__haskell' can have any of these requirements that I have seen (although some may be happy with any or all combinations, others may accept one specific format). (And the last one is trickiest when generating code because it doesn't simply go on the left of the type, or inside the type but to the left of the name or where the name goes, but goes deeper than that. Where does it go with int**? I'll have to investigate.) Then there are compilers that don't know about __haskell at all, but that is easier to deal with (although that will need to macros that tell you what the compiler is). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-27 15:30 +0100 |
| Message-ID | <87d1jpbekf.fsf@bsb.me.uk> |
| In reply to | #94133 |
BartC <bc@freeuk.com> writes: > On 27/09/2016 13:33, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 27/09/2016 08:48, David Brown wrote: >>>> On 26/09/16 22:32, supercat@casperkitty.com wrote: >>> >>>>> Should compiler writers not give programmers the opportunity to improve the >>>>> efficiency of their code by letting them tell the compiler which calling >>>>> conventions to use in different cases? >>> >>>> The problem here is that you have a single OS on a single hardware >>>> platform, with application level code - and you /still/ have a dozen >>>> different calling conventions to deal with, with each compiler having >>>> different details in how these are specified. >>> >>> Why doesn't the language acknowledge the existence of foreign >>> functions? >>> >>> That is, that there might be other languages that do things >>> differently, but a C program might want to call functions in that >>> other language, and vice versa. >> >> It does. The standard provides ways for implementations to call almost >> any sort of function. You might have >> >> extern __haskell fib(...); >> >> for example, or any of a thousand other possibilities. > >> If you mean why did the ISO committee not standardise any of these, I >> suspect you know the answer. I want to call into Haskell lazy >> functions, Ada rendezvous, SR remove procedures and static C++ method >> functions. What's your list? > > I'm not concerned with the details, only that an attribute /like/ > __haskell or __stdcall might exist. In that case, where should it go? > > For example: > > __haskell int* fib(); > int* __haskell fib(); > int __haskell * fib(); > > Any compilers that know about '__haskell' can have any of these > requirements that I have seen (although some may be happy with any or > all combinations, others may accept one specific format). Depending on the syntactic role it plays there is only one reasonable choice, but since I made it up on the spur of the moment, I had not decided if it is a type qualifier, a storage class specifier or a function-specifier. But if there are already different opinions about what kind of thing these modifiers are and therefore where they should go (I am just taking your word that that is the case) then there will be some objections to standardising it. However, since extensions are always going to be permitted under the blanket of UB, I wonder if any of the implementations would change where something like this standardised. It's probably easier to ask the offending implementations to change, or at least to accept the alternative syntax. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web