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 | 14 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 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-11 21:28 +0100 |
| Message-ID | <ntji0t$g9k$1@dont-email.me> |
| In reply to | #94743 |
On 11/10/2016 20:28, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > In any case, your point seems to be that MSVC is bloated. You're > probably right. The shortage of disk space on your personal system > isn't really relevant to that point. (If I had that little free space on > my system, I'd be doing something about it, but your own system is of > course your concern.) If sent you a Hello, World program so large that you needed to buy an extra drive to accommodate it, you would rightly balk at that. But for some reason people are more forgiving of language implementations even though they might be 10, 100 or 1000 times bigger than necessary. > What I fail to understand is what you hope to accomplish by complaining > about the size of MSVC here. I only pointed out that I found MSVC fiddly. Others mentioned that I ought to have a proper implementation, and I said its size was an impediment to my doing that (among other reasons since I refuse to download needlessly monstrous programs; also I doubt it would help. I only need MSVC to verify my C programs every so often). -- bartc
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2016-10-11 20:43 +0000 |
| Message-ID | <ntjiu5$go7$1@news.xmission.com> |
| In reply to | #94743 |
In article <lnk2den0qz.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: ... >What I fail to understand is what you hope to accomplish by complaining >about the size of MSVC here. About as much as you hope to accomplish by complaining here about him complaining here. Believe it or not, I actually understand Bart's reasons for posting - or at least I think I do. I have no clue why you post here. Quite seriously, how does it benefit you? -- Rich people pay Fox people to convince middle class people to blame poor people. (John Fugelsang)
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-10-11 23:40 -0500 |
| Message-ID | <j3frvbtp4lor094agb6mjns0d3ds7o15mk@4ax.com> |
| In reply to | #94712 |
On Tue, 11 Oct 2016 13:36:27 +0100, BartC <bc@freeuk.com> wrote:
>On 11/10/2016 12:08, already5chosen@yahoo.com wrote:
>> On Tuesday, October 11, 2016 at 12:57:03 PM UTC+3, Bart wrote:
>
>>> We're talking about a program that translates one input file to an
>>> output file. It's the simplest possible kind of application. What
>>> 'proper environment' is necessary?
>
>> Are you claiming that MS compiler installation is bloated? That's certainly true.
>>
>> Are you claiming that getting MS standalone compiler is tricky? That's certainly wrong.
>
>
>I have to be able to run a compiler from anywhere via a call such as this:
>
> system("c:/tcc32/tcc -c file.c 2>errors.tmp")
FWIW, if you have a proper installation, you just need to code the
above to execute something along the lines of:
cmd /s /c ""C:\Program Files\Microsoft Visual Studio
10.0\VC\vcvarsall.bat" &&cl test1.c>test1.log"
Depending on the version you have installed, vcvarsall.bat (or one of
the things it calls) hit the registry and/or some environment
variables from the install to set up the require environment and path.
Obviously the directory name will change depending on the version
installed (so you can have several versions installed). You can
specify a parameter to the batch file to select a particular
environment (ARM, x86-32, x86-32, IPF, etc.), although x86-32 is the
default.
You could build or use a batch file to make that string shorter, but I
don't see a big difference.
Alternatively, you could invoke the desired vcvarsall.bat in your IDE
startup, and then the C compiler will be in the path already.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-10-11 04:40 -0700 |
| Message-ID | <73ba6c9f-49dc-4f1a-872f-f816ccc11f9a@googlegroups.com> |
| In reply to | #94703 |
On Tuesday, October 11, 2016 at 12:57:03 PM UTC+3, Bart wrote: > > We're talking about a program that translates one input file to an > output file. It's the simplest possible kind of application. What > 'proper environment' is necessary? > They add few search paths to PATH: C:\Program Files (x86)\MSBuild\14.0\bin\amd64; C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64; C:\Windows\Microsoft.NET\Framework64\v4.0.30319; C:\Windows\Microsoft.NET\Framework64\; C:\Program Files (x86)\Windows Kits\8.1\bin\x64; C:\Program Files (x86)\Windows Kits\8.1\bin\x86; Probably, not strictly necessary, if you only care about compilation. They also add few variables to environment set: CommandPromptType=Native curDir=C:\Program Files (x86)\Microsoft Visual C++ Build Tools\ FrameworkDir=C:\Windows\Microsoft.NET\Framework64 FrameworkDIR64=C:\Windows\Microsoft.NET\Framework64 FrameworkVersion=v4.0.30319 FrameworkVersion64=v4.0.30319 INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE;C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt;C:\Program Files (x86)\Windows Kits\8.1\include\shared;C:\Program Files (x86)\Windows Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt; LIB=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64;C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x64;C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x64; LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\;References\CommonConfiguration\Neutral;\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral; UCRTContentRoot=C:\Program Files (x86)\Windows Kits\10\ UCRTVersion=10.0.10240.0 UniversalCRTSdkDir=C:\Program Files (x86)\Windows Kits\10\ VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140\ WindowsLibPath=References\CommonConfiguration\Neutral WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.1\ WindowsSDKLibVersion=winv6.3\ I'd guess that for compiling Posix-style "native" command-line applications most of those are also unnecessary, but INCLUDE and LIB are likely necessary. Anyway, even setting all those variables as part of invocation of compiler from within you IDE appear as simple as setting just a few that are really necessary. Do you prefer compilers that figure out locations of standard libraries and of standard include directories out of location of compiler executive? That's certainly simpler for your use case, but it is less flexible than looking at environment variables so not necessarily better for other use cases. Or do you prefer compilers that during installation add their settings to user's default environment? I personally don't like it at all, due to risk of name conflicts both against other compilers and against different versions of the same compiler.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-10 18:19 +0100 |
| Message-ID | <ntgij1$vhs$1@dont-email.me> |
| In reply to | #94681 |
On 10/10/2016 15:32, already5chosen@yahoo.com wrote: > On Monday, October 10, 2016 at 1:39:46 PM UTC+3, Bart wrote: >> >> I also have a part-working version of MSVC 32-bit (a seventh compiler), >> but this is fiddly to invoke so will only attempt trying it on the >> 'one-file' version of the project. >> >> -- >> Bartc > > Fiddly ? What does it mean? > > Few months ago I wrote an utility (interface definition processor) that invokes MSVC, as well as gcc, for various targets, as a part of its processing routine. Invocation part was trivial, as expected, as long as my utility was invoked in proper environment. In specific case of MSVC compiler "proper environment" was VS2013 x64 Native Tools Command Prompt. My MSVC version is a small 400MB installation intended for use for compiling CPython. (Small compared with a 5000-11000MB /compressed/ download of VS. But still 100 times bigger than Tiny C.) It only works within a special command prompt that has all the right settings. Even then, it only seemed to compile code if invoked from within its .\bin directory, which is located 11 directory levels deep from the root, and all source files are in the same location. I forget the exact details, but it means it's impractical to use it from my IDE, where usually I just press C (compile) or CA (compile all modules). In other words, fiddly. So I only drag it out on special occasions. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-10 09:08 -0700 |
| Message-ID | <lnzimcnq56.fsf@kst-u.example.com> |
| In reply to | #94680 |
BartC <bc@freeuk.com> writes:
> On 26/09/2016 14:31, BartC wrote:
> I've been finding yet more reasons to use and recommend only gcc to
> compile my projects. I've found two or three compiler bugs just in the
> last couple of days; they're supposed to be incredibly rare!
[...]
Who said compiler bugs are "incredibly rare"?
Most programmers are unlikely to encounter compiler bugs, and I've
seen a lot of inexperienced programmers who are too quick to blame
the compiler when their code doesn't compile. (That's not directed
at you.)
I worked on a (non-C) compiler at a previous job. It was reasonably
solid, but I don't remember whether our bug reporting system used
4 or 5 digits.
Pick any compiler with a publicly visible bug tracking system and
you'll see *lots* of bug reports.
My guess is that you're seeing more bugs than most programmers
would because you're compiling automatically generated code, so
you're more likely to hit odd corner cases.
I hope you're submitting bug reports; it's a good way to find
problems that might otherwise go undiscovered. (I did see one that
you posted in another newsgroup.)
--
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-10-10 18:04 +0100 |
| Message-ID | <ntghmj$rru$1@dont-email.me> |
| In reply to | #94684 |
On 10/10/2016 17:08, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 26/09/2016 14:31, BartC wrote:
>> I've been finding yet more reasons to use and recommend only gcc to
>> compile my projects. I've found two or three compiler bugs just in the
>> last couple of days; they're supposed to be incredibly rare!
> My guess is that you're seeing more bugs than most programmers
> would because you're compiling automatically generated code, so
> you're more likely to hit odd corner cases.
Maybe. But one problem with passing structs is illustrated here:
#include <stdio.h>
#include <stdint.h>
struct T {int32_t a,b;};
struct T testfn(struct T x) {
++x.a;
return x;
}
int main(void) {
struct T s = {100,200};
s = testfn(s);
printf("s = %d %d\n", s.a, s.b);
}
All compilers generate the same output: "s = 101 200", except for Tiny C
64 bits, which shows "s = 1244984 0" before crashing. (Oddly, the 32-bit
version is fine.)
But a corner case? Admittedly passing whole structs isn't common (I
chose the method here because I expected the 64-bit struct to be passed
as efficiently as a 64-bit int).
> I hope you're submitting bug reports;
Two of the compilers are no longer being maintained, making that a bit
awkward!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-10 10:39 -0700 |
| Message-ID | <6b0b3eff-2ffd-4c09-8848-828fe911b476@googlegroups.com> |
| In reply to | #94686 |
On Monday, October 10, 2016 at 12:04:44 PM UTC-5, Bart wrote: > But a corner case? Admittedly passing whole structs isn't common (I > chose the method here because I expected the 64-bit struct to be passed > as efficiently as a 64-bit int). Whether it's more efficient to pass a structure using one register for the whole thing, one register per value, or values on the stack stack, will depend upon how the structure is used both in the function and the calling code. My guess would be that the calling code is using one convention, but the called function is using another.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-10 11:25 -0700 |
| Message-ID | <lnvax0njsm.fsf@kst-u.example.com> |
| In reply to | #94686 |
BartC <bc@freeuk.com> writes:
> On 10/10/2016 17:08, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 26/09/2016 14:31, BartC wrote:
>>> I've been finding yet more reasons to use and recommend only gcc to
>>> compile my projects. I've found two or three compiler bugs just in the
>>> last couple of days; they're supposed to be incredibly rare!
>
>> My guess is that you're seeing more bugs than most programmers
>> would because you're compiling automatically generated code, so
>> you're more likely to hit odd corner cases.
>
> Maybe. But one problem with passing structs is illustrated here:
>
> #include <stdio.h>
> #include <stdint.h>
>
> struct T {int32_t a,b;};
>
> struct T testfn(struct T x) {
> ++x.a;
> return x;
> }
>
> int main(void) {
> struct T s = {100,200};
>
> s = testfn(s);
>
> printf("s = %d %d\n", s.a, s.b);
> }
>
> All compilers generate the same output: "s = 101 200", except for Tiny
> C 64 bits, which shows "s = 1244984 0" before crashing. (Oddly, the
> 32-bit version is fine.)
>
> But a corner case? Admittedly passing whole structs isn't common (I
> chose the method here because I expected the 64-bit struct to be
> passed as efficiently as a 64-bit int).
Just a data point: tcc 0.9.25 for x86-64 on Linux handles it correctly.
I won't try to guess whether the difference is in the release of tcc
you're using or a Linux vs. Windows thing. (FWIW, I see no problem with
the code.)
>> I hope you're submitting bug reports;
>
> Two of the compilers are no longer being maintained, making that a bit
> awkward!
Fair enough.
--
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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-10-10 17:05 -0400 |
| Message-ID | <ntgvpo$kkm$1@jstuckle.eternal-september.org> |
| In reply to | #94684 |
On 10/10/2016 12:08 PM, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 26/09/2016 14:31, BartC wrote: >> I've been finding yet more reasons to use and recommend only gcc to >> compile my projects. I've found two or three compiler bugs just in the >> last couple of days; they're supposed to be incredibly rare! > [...] > > Who said compiler bugs are "incredibly rare"? > Very true. I've found bugs in virtually every compiler I've ever used, from any developer. > Most programmers are unlikely to encounter compiler bugs, and I've > seen a lot of inexperienced programmers who are too quick to blame > the compiler when their code doesn't compile. (That's not directed > at you.) > > I worked on a (non-C) compiler at a previous job. It was reasonably > solid, but I don't remember whether our bug reporting system used > 4 or 5 digits. > No surprise there. As in your previous paragraph, most bugs reported are user errors, not compiler errors. Yet they still need to be tracked until they can be closed as user error. > Pick any compiler with a publicly visible bug tracking system and > you'll see *lots* of bug reports. > Yes, and in the midst of all of the user errors, you will find a fair number of real compiler bugs. > My guess is that you're seeing more bugs than most programmers > would because you're compiling automatically generated code, so > you're more likely to hit odd corner cases. > That's definitely a part of it. From his comments, I suspect Bart is also using more "new features" in his code. Newer features are more likely to have bugs than long-established features. > I hope you're submitting bug reports; it's a good way to find > problems that might otherwise go undiscovered. (I did see one that > you posted in another newsgroup.) > So do I. My favorite bug was in the Borland Turbo C++ compiler back in the early to mid 90's. One of my students in a beginning C++ class was getting storage problems (this was still MS-DOS based, so no storage protection). That night in my hotel I traced down the bug (for those who understand C++ and are interested, an object passed by reference had its destructor called on return - definite no-no). The next day at lunch I called Borland to report the bug (no internet reporting at the time). They wanted $35 for me to tell them about their bug! Back then, Borland never admitted to having bugs in their code. But every six months to a year, they came out with a new version of the compiler (that you had to pay for) with previous bugs magically disappearing, to be replaced by a new set of bugs. The joys of the internet. Borland tried to hide their bugs, but the bugs were all over usenet, CompuServe and other locations. The moral of the story is - you're writing code. You're going to have bugs. Own up to the bugs and get them fixed. Companies which don't do that will have a good chance of following Borland. They were just lucky someone decided to buy them. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-10 14:46 -0700 |
| Message-ID | <dcab55ba-451d-4100-85c9-6327f7f0d051@googlegroups.com> |
| In reply to | #94692 |
On Monday, October 10, 2016 at 4:05:22 PM UTC-5, Jerry Stuckle wrote:
> My favorite bug was in the Borland Turbo C++ compiler back in the early
> to mid 90's.
From what I understand, early C++ compilers from all vendors tended to be
buggy. The Turbo C compiler, seemed mostly pretty good. One fun bug in the
printf code, however, would cause it to incorrectly print values which are
just below a power of ten, but when rounded should print as a power of ten.
Given printf("%1.2f", 999.996); for example, the library would determine
that there needed to be three digits to the left of the decimal point (since
it was at least 100 but less than 1000) but would then perform the rounding
and output the pre-computed number of digits (i.e. 000.00). Oops.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-15 13:39 +0100 |
| Message-ID | <ntt815$i59$1@dont-email.me> |
| In reply to | #94680 |
On 10/10/2016 11:39, BartC wrote: > On 26/09/2016 14:31, BartC wrote: > > I've been finding yet more reasons to use and recommend only gcc to > compile my projects. I've found two or three compiler bugs just in the > last couple of days; they're supposed to be incredibly rare! Here's a version of the project I wanted to distribute as C source: https://github.com/bartg/langs/blob/master/pcc.c It compiles, as a 32-bit app, with Pelles C, lccwin, Tiny C and gcc. (It compiles with Digital Mars C, but that crashes when linking. DMC is quite old now though.) I can't test with clang but I expect it would work. It compiles also with MSVC but it might need tweaking if it doesn't recognise stdint.h. Instructions are in the source code. It should work under Windows or Linux (OS-specific stuff has been removed, so some things it can't do, but that still leaves a lot that it can.) Build instructions: compile the one C file (there are no user headers) and link it! Actually most compilers can compile and link it in one step. More details in the file. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-15 13:40 -0700 |
| Message-ID | <lnzim5gxcp.fsf@kst-u.example.com> |
| In reply to | #94866 |
BartC <bc@freeuk.com> writes:
[...]
> It compiles also with MSVC but it might need tweaking if it doesn't
> recognise stdint.h. Instructions are in the source code.
[...]
I believe MSVC does provide stdint.h.
https://msdn.microsoft.com/en-us/library/323b6b3k.aspx
--
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 | already5chosen@yahoo.com |
|---|---|
| Date | 2016-10-15 13:46 -0700 |
| Message-ID | <f3547974-04e7-4172-945f-82f1cecb356c@googlegroups.com> |
| In reply to | #94875 |
On Saturday, October 15, 2016 at 11:39:51 PM UTC+3, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] > > It compiles also with MSVC but it might need tweaking if it doesn't > > recognise stdint.h. Instructions are in the source code. > [...] > > I believe MSVC does provide stdint.h. > https://msdn.microsoft.com/en-us/library/323b6b3k.aspx > > -- > 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" Since 2010. It seems, Bart uses older MSVC.
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | comp.lang.c
csiph-web