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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-26 08:00 -0700 |
| Message-ID | <b7897e62-c0e6-4249-ab14-9d0cdca5980b@googlegroups.com> |
| In reply to | #94088 |
On Monday, September 26, 2016 at 9:26:37 AM UTC-5, Richard Heathfield wrote: > If you have to ship platform-specific code, you're going to hit > platform-specific problems that have platform-specific solutions best > discussed in platform-specific newsgroups. One of the major purposes of a standard should be to ensure that if people writing implementations for some hardware platform need to solve a common problem, they will be likely to do so in the same way. While the C Standard tries to avoid providing recommendations that are not requirements, many standards gain much of their utility from their recommendations. If someone is writing code to exploit some unique hardware features of a platform for which there exist three C implementations and wants to make it usable on all three implementations for that hardware platform, the person would obviously have to read the hardware documentation for that platform. A useful standard, however, would make it likely that code which was written for any of the three C implementations would work for all of them. If the Standard says implementations should do X "when practical" there may be some cases where two compiler writers decided X was practical and one did not, but in most cases it will be fairly obvious what is practical and what isn't, and thus compiler writers would *usually* do the same thing.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-28 10:49 -0700 |
| Message-ID | <kfn1t03c3tq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #94090 |
supercat@casperkitty.com writes: > On Monday, September 26, 2016 at 9:26:37 AM UTC-5, Richard Heathfield wrote: >> If you have to ship platform-specific code, you're going to hit >> platform-specific problems that have platform-specific solutions >> best discussed in platform-specific newsgroups. > > One of the major purposes of a standard should be to ensure that > if people writing implementations for some hardware platform need > to solve a common problem, they will be likely to do so in the > same way. [...] That may be a purpose of some standards, but it is not a purpose of the ISO C standard. And rightly so.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-26 17:30 +0100 |
| Message-ID | <nsbif5$v6v$1@dont-email.me> |
| In reply to | #94088 |
On 26/09/2016 15:26, Richard Heathfield wrote: > On 26/09/16 15:12, BartC wrote: >> On 26/09/2016 14:45, Richard Heathfield wrote: >>> On 26/09/16 14:31, BartC wrote: >> >>>> This means if I distribute a project as C source code, I will need to >>>> recommend gcc to compile it. Or Tiny C. >>> >>> Or just write it in ISO C, and ship it without any recommendation >>> needed. Let them use whatever conforming implementation they like. >> >> If the C needs to call Windows (or a C function is a callback function >> called from Windows), then things like __stdcall and >> __declspec(dllimport) appear to be necessary. > > If you have to ship platform-specific code, you're going to hit > platform-specific problems that have platform-specific solutions best > discussed in platform-specific newsgroups. No, that sort of problem I can deal with. I don't think it's even a C issue apart from needing LoadLibrary/GetProcAddress in one context and dlopen/dlsym in another. But sometimes with a foreign function or function pointer you have to specify the call-convention or other attribute associated with it. The __stdcall one has been around a long time and you'd think that compilers would have agreed on where exactly to stick it! And I doubt an MS Windows group is going to help with why one C compiler - not MSVC - is very fussy about the exact placement while another doesn't allow it inside a cast. Apparently the solution, according to David Brown, is not to fix the various compilers but to introduce lots of conditional macros enumerated by target compiler. I think where the language can help is to acknowledge the existence of implementation specific attributes and give guidelines as to where they should be placed. A long-term fix though; it won't help me today. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-26 21:12 +0200 |
| Message-ID | <nsbrve$4hg$1@dont-email.me> |
| In reply to | #94093 |
On 26/09/16 18:30, BartC wrote: > On 26/09/2016 15:26, Richard Heathfield wrote: >> On 26/09/16 15:12, BartC wrote: >>> On 26/09/2016 14:45, Richard Heathfield wrote: >>>> On 26/09/16 14:31, BartC wrote: >>> >>>>> This means if I distribute a project as C source code, I will need to >>>>> recommend gcc to compile it. Or Tiny C. >>>> >>>> Or just write it in ISO C, and ship it without any recommendation >>>> needed. Let them use whatever conforming implementation they like. >>> >>> If the C needs to call Windows (or a C function is a callback function >>> called from Windows), then things like __stdcall and >>> __declspec(dllimport) appear to be necessary. >> >> If you have to ship platform-specific code, you're going to hit >> platform-specific problems that have platform-specific solutions best >> discussed in platform-specific newsgroups. > > No, that sort of problem I can deal with. I don't think it's even a C > issue apart from needing LoadLibrary/GetProcAddress in one context and > dlopen/dlsym in another. > > But sometimes with a foreign function or function pointer you have to > specify the call-convention or other attribute associated with it. The > __stdcall one has been around a long time and you'd think that compilers > would have agreed on where exactly to stick it! > > And I doubt an MS Windows group is going to help with why one C compiler > - not MSVC - is very fussy about the exact placement while another > doesn't allow it inside a cast. > > Apparently the solution, according to David Brown, is not to fix the > various compilers but to introduce lots of conditional macros enumerated > by target compiler. Well, of course that is the solution. Do you think /you/ can persuade all the compiler manufacturers to change to suit /you/ ? 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. Posix is not perfect here either, but you can get a lot further towards writing a single piece of standard ISO C code and having it compile with a wide range of compilers on a wide range of *nix OS's. I can think of several possible ways to handle the situation: 1. Complain to Microsoft, and insist that they define a single sensible, consistent ABI to be used on Windows. Make sure that all compilers for Windows use that ABI and calling convention, and that they use it by default so that you don't need implementation-specific extensions to call libraries. Make sure that everyone who makes libraries and DLL's for Windows follows those rules. 2. Use macros to wrap the implementation-dependent parts as neatly as possible, in a way that should cause no challenges to machine-generated C code. 3. Moan about it in newsgroups to people who have nothing to do with the problem, and are content to use macro workarounds if they were in the same situation. 4. Throw your hands up in the air in despair, because you can only support one compiler for your tools, and you always have trouble installing that tool. 5. Re-invent autotools with a Windows version. Personally, I'd go for solution number 2. It should take less time than writing the posts in this thread.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-09-26 22:09 +0200 |
| Message-ID | <nsbv8t$hiv$1@dont-email.me> |
| In reply to | #94099 |
Le 26/09/2016 à 21:12, David Brown a écrit : > 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. The windows API has been stable for around 15-20 years. Code prted from 16 bit windows 3.1 is still running today on windows 10. See the debugger and the IDE of lcc-win, written using the windows API. _stdcall is not so critical now, and lcc-win doesn't use it anymore. It was supposed to allow functions with a fixed number of arguments to clean the stack after they are done. Now, with the first 4 arguments passed in register, the utility of stdcall is very low, and is not used in the windows API any more. All compilers that I know of are using stdcall in the same manner under windows. They could not generate a call to the windows API if they weren't. I do not want to start a "My os is better than yours" discussion because I do not use very much windows any more but it is better to remind all the linux peoçple that they ported from one version of GTK+ to the next during all these years. jacob
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-26 13:32 -0700 |
| Message-ID | <591c35dc-315d-4293-bf36-53ffa8eb044d@googlegroups.com> |
| In reply to | #94099 |
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?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-09-26 23:14 +0200 |
| Message-ID | <nsc338$v6f$1@dont-email.me> |
| In reply to | #94106 |
Le 26/09/2016 à 22:32, supercat@casperkitty.com a écrit : > 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? If we follow Mr Heathfield the answer is NO. What do you want? A program that runs smoothly and fast? No! A program that does nothing but will run from the 6502 to the Cray computer? Yes!
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-26 22:47 +0100 |
| Message-ID | <nsc51s$67e$1@dont-email.me> |
| In reply to | #94109 |
On 26/09/16 22:14, jacobnavia wrote: > Le 26/09/2016 à 22:32, supercat@casperkitty.com a écrit : >> 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? > > If we follow Mr Heathfield the answer is NO. On the contrary, I'm all for the idea of compiler writers providing flexibility in their compilers by supplying extensions that are topical in compiler-specific newsgroups. > What do you want? > > A program that runs smoothly and fast? > > No! Well, yes, sometimes. > > A program that does nothing but will run from the 6502 to the Cray > computer? > > Yes! Well, no, a program that does nothing isn't much use (except for IEFBR14, of course). Of course we sometimes need platform-specific functionality. And sometimes we get stuck with that, and need help. And the place to look for that help is in platform-specific newsgroups. You don't do sarcasm very well, and as usual you didn't think it through. You seem to think that Usenet is all one piece. It isn't. It's divided up into subject areas, and for good reason. Discussing compiler extensions here is like cooking in the bathroom or posting letters into the fishpond or mowing the roof. When people suggest you shouldn't cook in the bathroom, that doesn't mean they're anti-cooking. They're just pointing out that there are better places to do your cooking. Similarly, people who suggest that compiler-specific stuff is better discussed in compiler-specific newsgroups aren't being anti-extensions. They're just pointing out that there are better places to discuss extensions. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-27 01:13 +0100 |
| Message-ID | <nscdi3$1md$1@dont-email.me> |
| In reply to | #94110 |
On 26/09/2016 22:47, Richard Heathfield wrote: > You don't do sarcasm very well, and as usual you didn't think it > through. You seem to think that Usenet is all one piece. It isn't. It's > divided up into subject areas, and for good reason. Discussing compiler > extensions here is like cooking in the bathroom or posting letters into > the fishpond or mowing the roof. Imagine there are two shops A and B next to each other. A has a car park. So it makes sense, if you're passing by, to park your car, buy things you need in A, then pop next door to B for a second since you happen to be there. However the car park belongs to A and only A's customers are allowed to park there. Which means that after buying your things in A, they expect you to drive home, leave your car there, then go a catch a bus back to shop B to buy that one item, then get the bus back! Well, this group is like the car park, A is the C language, and B is those extra bits of the language that everyone needs to use. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-27 01:18 +0100 |
| Message-ID | <nscdsn$281$1@dont-email.me> |
| In reply to | #94112 |
On 27/09/16 01:13, BartC wrote: > On 26/09/2016 22:47, Richard Heathfield wrote: > >> You don't do sarcasm very well, and as usual you didn't think it >> through. You seem to think that Usenet is all one piece. It isn't. It's >> divided up into subject areas, and for good reason. Discussing compiler >> extensions here is like cooking in the bathroom or posting letters into >> the fishpond or mowing the roof. > > Imagine there are two shops A and B next to each other. A has a car park. > > So it makes sense, if you're passing by, to park your car, buy things > you need in A, then pop next door to B for a second since you happen to > be there. > > However the car park belongs to A and only A's customers are allowed to > park there. Which means that after buying your things in A, they expect > you to drive home, leave your car there, then go a catch a bus back to > shop B to buy that one item, then get the bus back! > > Well, this group is like the car park, A is the C language, and B is > those extra bits of the language that everyone needs to use. That is a spectacularly bad analogy that bears no relation whatsoever to the structure of Usenet. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-26 17:41 -0700 |
| Message-ID | <lneg46tbqt.fsf@kst-u.example.com> |
| In reply to | #94112 |
BartC <bc@freeuk.com> writes:
> On 26/09/2016 22:47, Richard Heathfield wrote:
>> You don't do sarcasm very well, and as usual you didn't think it
>> through. You seem to think that Usenet is all one piece. It isn't. It's
>> divided up into subject areas, and for good reason. Discussing compiler
>> extensions here is like cooking in the bathroom or posting letters into
>> the fishpond or mowing the roof.
>
> Imagine there are two shops A and B next to each other. A has a car park.
>
> So it makes sense, if you're passing by, to park your car, buy things
> you need in A, then pop next door to B for a second since you happen to
> be there.
>
> However the car park belongs to A and only A's customers are allowed to
> park there. Which means that after buying your things in A, they expect
> you to drive home, leave your car there, then go a catch a bus back to
> shop B to buy that one item, then get the bus back!
>
> Well, this group is like the car park, A is the C language, and B is
> those extra bits of the language that everyone needs to use.
Right, because posting to a different newsgroup is just as inconvenient
as driving home, leaving your care there, catching a bus, going into a
shop, and then catching another bus home again.
Oh, wait, it isn't.
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-09-27 02:01 +0100 |
| Message-ID | <nscgdp$8kn$1@dont-email.me> |
| In reply to | #94117 |
On 27/09/2016 01:41, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> Imagine there are two shops A and B next to each other. A has a car park. >> >> So it makes sense, if you're passing by, to park your car, buy things >> you need in A, then pop next door to B for a second since you happen to >> be there. >> >> However the car park belongs to A and only A's customers are allowed to >> park there. Which means that after buying your things in A, they expect >> you to drive home, leave your car there, then go a catch a bus back to >> shop B to buy that one item, then get the bus back! >> >> Well, this group is like the car park, A is the C language, and B is >> those extra bits of the language that everyone needs to use. > > Right, because posting to a different newsgroup is just as inconvenient > as driving home, leaving your care there, catching a bus, going into a > shop, and then catching another bus home again. > > Oh, wait, it isn't. Finding a suitable newsgroup (and that is still active) *can* be as big a nuisance. It's easier to ask a question here than go home to take the bus. In my comments I didn't say which compilers had trouble with __stdcall, and I don't even know whether it is specific to an OS platform or to an architecture. So which group would be the best bet for useful feedback? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-27 08:41 -0700 |
| Message-ID | <lna8ettknv.fsf@kst-u.example.com> |
| In reply to | #94119 |
BartC <bc@freeuk.com> writes:
[...]
> Finding a suitable newsgroup (and that is still active) *can* be as big
> a nuisance. It's easier to ask a question here than go home to take the bus.
>
> In my comments I didn't say which compilers had trouble with __stdcall,
> and I don't even know whether it is specific to an OS platform or to an
> architecture. So which group would be the best bet for useful feedback?
For gcc, there are several gnu.gcc.* newsgroups.
For lcc, there's comp.compilers.lcc.
For Windows programming in general, there's
comp.os.ms-windows.programmer.win32.
And there are resources other than Usenet, for example Stack Overflow.
--
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 | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-09-27 01:41 +0100 |
| Message-ID | <nscf6u$5nf$1@dont-email.me> |
| In reply to | #94110 |
On 26/09/2016 22:47, Richard Heathfield wrote: ... > Discussing compiler > extensions here is like cooking in the bathroom or posting letters into > the fishpond or mowing the roof. When people suggest you shouldn't cook > in the bathroom, that doesn't mean they're anti-cooking. They're just > pointing out that there are better places to do your cooking. Given that there is a newsgroup comp.std.c what is there to say that comp.lang.c is just about 'standard' C? I thought there were 'mandates' for each newsgroup but cannot find them ATM. -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-09-26 18:15 -0700 |
| Message-ID | <ee2fa03f-3d00-4ad3-877b-45d22dc9476c@googlegroups.com> |
| In reply to | #94116 |
Usenet newsgroups are supposed to have charters, but comp.lang.c predates that requirement. comp.std.c is a different matter. It has a charter which specifies that it is for discussions of the C standard: what it means, proposed changes, etc. It is NOT for discussion of standard C - how to use the language described by that standard. That there are better places to discuss particular implementations of C is just a matter of fact, it's not something that follows from the words of comp.lang.c's non-existent charter. Almost every implementation of C has at least one forum specialized for discussion of that implementation. The biggest implementations have hundreds of such forums. Those forums are generally the best place to discuss implementation-specific issues. That leaves comp.lang.c, by default, as the place to discuss implementation-independent aspects of C. Not because it has a charter that says so, just because there are better places for all other C-related discussions.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-09-27 20:59 +0100 |
| Message-ID | <871t05w1up.fsf@gmail.com> |
| In reply to | #94116 |
James Harris <james.harris.1@gmail.com> writes: > On 26/09/2016 22:47, Richard Heathfield wrote: > > Given that there is a newsgroup comp.std.c what is there to say that > comp.lang.c is just about 'standard' C? There is Richard and Keith to say it. Almost no-one else says it, but they say it with such fervor and frequency that people who aren't paying attention may actually believe there is some objective basis for it. > I thought there were 'mandates' for each newsgroup but cannot find > them ATM. c.l.c. predates charters.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-27 21:50 +0100 |
| Message-ID | <nsem2e$vhn$1@dont-email.me> |
| In reply to | #94163 |
On 27/09/16 20:59, Gareth Owen wrote: > James Harris <james.harris.1@gmail.com> writes: > >> On 26/09/2016 22:47, Richard Heathfield wrote: >> >> Given that there is a newsgroup comp.std.c what is there to say >> that comp.lang.c is just about 'standard' C? > > There is Richard and Keith to say it. Almost no-one else says it, > but they say it with such fervor and frequency that people who aren't > paying attention may actually believe there is some objective basis > for it. Actually, I don't say it all that often nowadays. But there /is/ an objective basis for it: comp.std.c discusses the C Standard, and comp.lang.c discusses standard C. Various compiler-specific groups discuss compiler-specific stuff. What's so hard to understand? >> I thought there were 'mandates' for each newsgroup but cannot find >> them ATM. > > c.l.c. predates charters. It would appear that the hyphen is optional, but I always read "predates" as something a carnivore does, so you've given me the image of Keith and James and Ben and Tim stalking a charter through the undergrowth. It accelerates away from them, only to find John Bode lurking behind a tree and ready to pounce. The end, when it comes, is very messy. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-28 06:26 -0700 |
| Message-ID | <kfnzimsb1et.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #94168 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 27/09/16 20:59, Gareth Owen wrote: >> James Harris <james.harris.1@gmail.com> writes: >> >>> I thought there were 'mandates' for each newsgroup but cannot >>> find them ATM. >> >> c.l.c. predates charters. > > It would appear that the hyphen is optional, but I always read > "predates" as something a carnivore does, [...] After consulting some online dictionaries, it appears that the sense of "to seek prey" is a back-formation from "predator", and is fairly recent. The more common usage of "precedes in time" not only predates the "seek prey" usage, it predates the word "predator" itself by about fifty years.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2016-09-27 23:23 +0000 |
| Message-ID | <nsev27$fia$1@news.xmission.com> |
| In reply to | #94163 |
In article <871t05w1up.fsf@gmail.com>, Gareth Owen <gwowen@gmail.com> wrote: >James Harris <james.harris.1@gmail.com> writes: >> Given that there is a newsgroup comp.std.c what is there to say that >> comp.lang.c is just about 'standard' C? > >There is Richard and Keith to say it. Almost no-one else says it, but >they say it with such fervor and frequency that people who aren't paying >attention may actually believe there is some objective basis for it. +1 But it's not just Heathfield and Thompson, although they may be about all that's left of the old guard at this late date. Anyway, CLC is what it is - and it wouldn't be anywhere near as amusing if those who constantly screech "off topic" were no longer doing so. -- Watching ConservaLoons playing with statistics and facts is like watching a newborn play with a computer. Endlessly amusing, but totally unproductive.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2016-10-08 00:12 +0200 |
| Message-ID | <nt96k2$v2k$1@dont-email.me> |
| In reply to | #94163 |
On 27/09/2016 21:59, Gareth Owen wrote: > James Harris <james.harris.1@gmail.com> writes: > >> On 26/09/2016 22:47, Richard Heathfield wrote: >> >> Given that there is a newsgroup comp.std.c what is there to say that >> comp.lang.c is just about 'standard' C? > > There is Richard and Keith to say it. Almost no-one else says it, but > they say it with such fervor and frequency that people who aren't paying > attention may actually believe there is some objective basis for it. Wait, what?! No one else says to stop posting OT crap in comp.lang.c ? "Listen up everyone, stop posting OT crap to comp.lang.c" > c.l.c. predates charters. Doesn't mean anyone can post anything about toolchains, assembly code, linkers, optimization levels, debugging tools, IDEs, etc.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web