Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91437 > unrolled thread
| Started by | luser droog <luser.droog@gmail.com> |
|---|---|
| First post | 2016-07-31 15:31 -0700 |
| Last post | 2016-08-08 22:12 -0700 |
| Articles | 20 on this page of 144 — 28 participants |
Back to article view | Back to comp.lang.c
Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-07-31 15:31 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-07-31 15:52 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:21 -0700
Re: Extending C with GC? Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-01 20:34 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-01 12:14 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 12:46 -0700
Re: Extending C with GC? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-01 15:56 -0400
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 14:28 -0700
Re: Extending C with GC? Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-01 23:37 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 15:03 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-02 00:11 +0200
Re: Extending C with GC? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-01 18:19 -0400
Re: Extending C with GC? BGB <cr88192@hotmail.com> - 2016-08-02 12:46 -0500
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-03 15:26 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-03 15:49 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-04 14:07 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-03 19:26 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-04 14:55 +1200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-03 20:38 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 05:10 -0700
Re: Extending C with GC? Siri Cruise <chine.bleu@yahoo.com> - 2016-08-04 05:57 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 06:13 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-05 07:24 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 12:47 -0700
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:32 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 10:09 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-05 20:32 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-05 06:14 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 04:14 -0700
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-06 13:23 +0200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 04:38 -0700
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 04:34 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 05:28 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 06:05 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 06:12 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:02 +0100
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 06:11 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:50 +0100
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 07:57 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 17:02 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:20 +0200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-06 14:27 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:45 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 09:59 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-06 19:38 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 17:03 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 09:54 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-07 21:53 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 11:34 +0100
Re: Extending C with GC? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-07 12:06 +0000
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-07 14:10 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 15:38 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 14:32 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 23:44 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 16:12 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 01:42 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 18:56 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:20 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-08 09:39 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 02:30 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 20:15 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 01:24 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 02:08 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 18:49 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 03:28 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 12:14 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 07:37 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 20:56 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 08:11 +1200
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-07 22:19 +0200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 22:23 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 14:29 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 22:36 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 15:04 -0700
Re: Extending C with GC? jameskuyper@verizon.net - 2016-08-07 15:19 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 00:04 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 16:20 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:21 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:35 +0100
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-08 18:13 +0100
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-08 11:53 -0700
Re: Extending C with GC? raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:58 +0000
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-10 07:05 -0700
Re: Extending C with GC? Ken Brody <kenbrody@spamcop.net> - 2016-08-10 12:29 -0400
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 21:15 +0100
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-08 08:57 -0700
Re: Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-08-07 15:37 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 14:58 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:26 +1200
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 10:26 +0200
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 21:13 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:41 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 12:00 +0200
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 22:07 +1200
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-08 12:57 +0200
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-08 18:12 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 21:25 +1200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 02:57 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 13:28 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 05:42 -0700
Re: Extending C with GC? Florian Weimer <fw@deneb.enyo.de> - 2016-08-07 11:49 +0200
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:18 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-06 12:35 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:27 +0200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 10:55 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-06 12:31 -0700
Re: Extending C with GC? James Kuyper <jameskuyper@verizon.net> - 2016-08-03 22:36 -0400
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-04 10:57 +0200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 04:09 -0700
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-04 14:01 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 07:52 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 08:57 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 09:19 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-04 12:30 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 15:21 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-04 16:50 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-05 07:31 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 16:01 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-04 21:00 +0200
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-04 20:26 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 10:37 +0200
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:52 +0100
Re: Extending C with GC? antispam@math.uni.wroc.pl - 2016-08-21 00:09 +0000
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-21 08:58 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-21 10:48 +0200
Re: Extending C with GC? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2016-08-21 19:58 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-22 08:46 -0700
Re: Extending C with GC? Öö Tiib <ootiib@hot.ee> - 2016-08-26 02:24 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-26 13:37 -0700
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-27 00:41 +0200
Re: Extending C with GC? Öö Tiib <ootiib@hot.ee> - 2016-08-28 06:12 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-05 10:06 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:26 +0100
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:11 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 17:43 +0200
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:28 -0700
Re: Extending C with GC? BGB <cr88192@hotmail.com> - 2016-08-04 17:11 -0500
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:35 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-01 07:45 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 08:49 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-01 09:06 -0700
Re: Extending C with GC? Aleksandar Kuktin <akuktin@gmail.com> - 2016-08-05 18:11 +0000
Re: Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-08-05 11:24 -0700
Re: Extending C with GC? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-08 22:12 -0700
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-08 11:53 -0700 |
| Message-ID | <18754f70-8485-4425-a253-5f6425c053fd@googlegroups.com> |
| In reply to | #91978 |
On Monday, August 8, 2016 at 12:13:40 PM UTC-5, gwowen wrote: > > Any compiler *I* produce can be built with simple instructions (partly > > because I keep them simple, partly because I MAKE THE EFFORT). > > Well, that's one of the advantages of software that only ever needs to > be run on one machine. It should be possible and practical to extend the Standard in such a way that a large fraction of programs could simply be distributed as a bunch of C files, header files, and configuration files such that simply feeding everything to a standard implementation would either yield an executable that behaves according to requirements or else identify an optional feature that the program requires but the platform does not support. There are some kinds of program where multi-platform support will necessarily be complex, but there are many others for which a simpler approach would be much more helpful.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-08-10 12:58 +0000 |
| Message-ID | <57ab24b5.7911343@news.xs4all.nl> |
| In reply to | #91983 |
supercat@casperkitty.com wrote: > On Monday, August 8, 2016 at 12:13:40 PM UTC-5, gwowen wrote: > > > Any compiler *I* produce can be built with simple instructions (partly > > > because I keep them simple, partly because I MAKE THE EFFORT). > > > > Well, that's one of the advantages of software that only ever needs to > > be run on one machine. > > It should be possible and practical to extend the Standard in such a way > that a large fraction of programs could simply be distributed as a bunch > of C files, header files, and configuration files such that simply feeding > everything to a standard implementation would either yield an executable > that behaves according to requirements or else identify an optional feature > that the program requires but the platform does not support. I see you've never met an end user, either, like so many of the experts in this group. I've said many things about Bart, but at least he natively understands the low level you must stoop to if the average user is to install and run your programs. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-10 07:05 -0700 |
| Message-ID | <f6ee49b0-8ca7-4293-bcdf-e69d01895673@googlegroups.com> |
| In reply to | #92061 |
On Wednesday, August 10, 2016 at 7:59:01 AM UTC-5, Richard Bos wrote: > > It should be possible and practical to extend the Standard in such a way > > that a large fraction of programs could simply be distributed as a bunch > > of C files, header files, and configuration files such that simply feeding > > everything to a standard implementation would either yield an executable > > that behaves according to requirements or else identify an optional feature > > that the program requires but the platform does not support. > > I see you've never met an end user, either, like so many of the experts > in this group. Obviously for many users on common platforms the preferred approach is going to be to distribute executables that the platform can simply use. Otherwise, I'm not sure what you're objecting to. Are end users expected to have an easier time with build scripts that will need to be customized for every compiler, with a failure to customize things properly yielding an executable file that may 99% work, but fail at inopportune moments, versus having a set of source files that can only have one possible meaning and when processed will either yield that meaning or be rejected altogether? \
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2016-08-10 12:29 -0400 |
| Message-ID | <nofkq1$s6d$1@dont-email.me> |
| In reply to | #92061 |
On 8/10/2016 8:58 AM, Richard Bos wrote: > supercat@casperkitty.com wrote: > >> On Monday, August 8, 2016 at 12:13:40 PM UTC-5, gwowen wrote: >>>> Any compiler *I* produce can be built with simple instructions (partly >>>> because I keep them simple, partly because I MAKE THE EFFORT). >>> >>> Well, that's one of the advantages of software that only ever needs to >>> be run on one machine. >> >> It should be possible and practical to extend the Standard in such a way >> that a large fraction of programs could simply be distributed as a bunch >> of C files, header files, and configuration files such that simply feeding >> everything to a standard implementation would either yield an executable >> that behaves according to requirements or else identify an optional feature >> that the program requires but the platform does not support. > > I see you've never met an end user, either, like so many of the experts > in this group. [...] I don't know if I would consider myself an "expert" -- just someone who has been writing in C for about 30 years, and ported software to numerous platforms. (Note, however, that all the platforms are [mostly] POSIX compliant, so I deal with POSIX, and not ISO C.) But, even after all these years, I can still learn something from here. Sometimes, it's something that was standardized after the K&R C which I started with. Other times, it's "un-learning" something I mis-learned many years ago. I've met many end users, and hang out on a (3rd party) mailing list for the software I write/maintain. I've also gotten to the point that, when an end-user asks "how do I do X", I answer the question as-asked, and have given up asking "why would you want to". I also have to deal with reports of "this code no longer works because something in $PROGRAM changed", when nearly always my response is "that code could never have worked". They'll always insist "it used to work", at which point I'll request that they try it again on the previous version of $PROGRAM, and if it worked as they describe, send files to demonstrate the change in $PROGRAM's behavior. Without fail, they'll eventually reply along the lines of "I could've sworn it worked before". So, yes, I've dealt with (and met in-person) many end users. -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-08 21:15 +0100 |
| Message-ID | <noap90$urp$1@dont-email.me> |
| In reply to | #91978 |
On 08/08/2016 18:13, Gareth Owen wrote: > BartC <bc@freeuk.com> writes: > >> On 08/08/2016 04:21, Ian Collins wrote: >>> On 08/ 8/16 11:04 AM, BartC wrote: >>>> >>>> I believe in having a C compiler (and linker), and simple human-readable >>>> /instructions/ on how to build a project. (Have the make-file too if you >>>> like but not instead of.) >>> >>> Good luck building something small like an OS kernel, or a compiler with >>> a C compiler and simple instructions. See you back here next year. >> >> Any compiler *I* produce can be built with simple instructions (partly >> because I keep them simple, partly because I MAKE THE EFFORT). > > Well, that's one of the advantages of software that only ever needs to > be run on one machine. One actual machine, or one platform? If I want to share code, I make it available as more-or-less portable C code. Then it can work on x86, x64 or ARM; and (depending on what it does) on Windows or Linux. That covers quite a lot of ground. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-08 08:57 -0700 |
| Message-ID | <2b1c4228-29f9-407a-9d73-ae6075009431@googlegroups.com> |
| In reply to | #91882 |
On Sunday, August 7, 2016 at 5:19:17 PM UTC-5, james...@verizon.net wrote: > In addition, since the standard defines an implementation as "particular set of software, running in a particular translation environment under particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment" (3.12p2), you can't have a complete C implementation without also having a CPU, and some kind of data storage, and the software must already be running on that CPU - otherwise it doesn't qualify as an implementation. > > I've been arguing that software alone can't qualify as a conforming implementation for years, but I only recently discovered that it's the standard's definition of "implementation" which justifies my claim. I'd been concentrating on the "conforming" aspect, and arguments based upon conformance necessarily addressed the issue less directly: a conforming implementation is required to produce certain kinds of behavior when translating or executing a program, and software that is not currently executing can neither translate a program, nor execute it, nor produce the required behavior. People for some reason found that a less convincing argument, though it seems pretty strong to me. However, the use of "running" in the present tense in 3.12p1 makes it clearer. This is part of why I've been thinking that the Standard really needs to separate out the compiler from the execution environment. If one has a compiler plus an execution-environment specification, such that taking the output from the compiler and running it in any environment meeting the specification will yield the behaviors described by the Standard, then it should be possible to define a standard for compiler compliance. It should then be possible to distinguish between compiler-generated UB and environment-generated UB.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-08-07 15:37 -0700 |
| Message-ID | <16feeae3-5612-4884-8884-5422074e2597@googlegroups.com> |
| In reply to | #91878 |
On Sunday, August 7, 2016 at 4:37:04 PM UTC-5, Bart wrote: > On 07/08/2016 22:29, Rick C. Hodgin wrote: > > Bartc wrote: > >> The brick wall is when the build instructions say type > >> ./configure and that doesn't work because you're not > >> running linux/unix/whatever. > > > > Install cygwin. It gives you the appropriate bash terminal, and > > allows linux/unix/whatever on Windows, with generated binaries > > which run on Windows natively. > > I tried MSYS last time I made a serious attempt. It didn't work. > > My gripe however is with having to install either MSYS or CYGWIN. > > For a C application, why do you need anything beyond a C compiler? > The hot ticket I discovered is MSYS2. Grab that first, then use its nice gui package manager to install a mingw32 or -64 build system. More details on my friend's quick guide: http://vtorri.github.io/examine/ (also check out his clone of valgrind's "memcheck" for windoze at the same address).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-07 14:58 -0700 |
| Message-ID | <lntweww89r.fsf@kst-u.example.com> |
| In reply to | #91875 |
BartC <bc@freeuk.com> writes:
> On 07/08/2016 21:11, Ian Collins wrote:
>> On 08/ 8/16 07:56 AM, BartC wrote:
[...]
>>> Are we still talking about C code?
No -- so why are you still talking about it *here*?
>>> And how exactly does it take account
>>> of these systems? Is the application written in C, or is it actually
>>> written in Bash?
>>
>> By checking the system headers, checking what libraries and what version
>> of those libraries are installed, checking what compilers (and which
>> versions) are installed, checking the system architecture, system OS
>> (and version) and what ever else is required to build the code.
>
> And that takes tens of thousands of lines of of code?
>
> What does it do with the result? What's the role of make files in all
> this, or is that yet another level?
Have you considered doing some research? There are manuals and books
describing how autoconf works. The first Google hit for "autoconf" is
the GNU project web page; it has a brief description and a link to the
documentation in several formats.
[...]
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-08 15:26 +1200 |
| Message-ID | <e0qcedFdmg1U2@mid.individual.net> |
| In reply to | #91875 |
On 08/ 8/16 09:23 AM, BartC wrote: > On 07/08/2016 21:11, Ian Collins wrote: >> On 08/ 8/16 07:56 AM, BartC wrote: >>> On 07/08/2016 20:37, Ian Collins wrote: >>>> On 08/ 7/16 10:34 PM, BartC wrote: >>> >>>>> On my machine that doesn't work. Because it's designed to be meaningful >>>>> only on Linux or something that emulates Linux. >>>> >>>> Nope, the process predates Linux. >>> >>> Linux, Unix, whatever. >> >> The whatever is important. >> >>>> One reason configure scripts are so big is to take into account all of >>>> the possible (and often long dead) systems the code might get built on. >>> >>> Are we still talking about C code? And how exactly does it take account >>> of these systems? Is the application written in C, or is it actually >>> written in Bash? >> >> By checking the system headers, checking what libraries and what version >> of those libraries are installed, checking what compilers (and which >> versions) are installed, checking the system architecture, system OS >> (and version) and what ever else is required to build the code. > > And that takes tens of thousands of lines of of code? Who cares? Do you care how many lines of code it takes to open a web page? > What does it do with the result? What's the role of make files in all > this, or is that yet another level? You know full well what it does. >>> But I'm told I can't just type 'cc file.c' because I first have to run a >>> script, in a language >> >> The script is in the lowest common denominator language. Every system >> the code is targeted at will have it. > > Well, my system doesn't. Importing most of Linux to make it 'have' it > doesn't count. And if I did have it, I still wouldn't want it. I like to > have my own streamlined build procedures. So keep on pushing shit up hill and stop whinging. > This configure/make palaver is very unfriendly outside the Linux world > and is overkill IMO. It's taking something that could be very simple, > and making it impossible. It's friendly everywhere except for the Windows world for users too pig headed to install Cygwin... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-08 10:26 +0200 |
| Message-ID | <no9fo7$gi0$1@dont-email.me> |
| In reply to | #91917 |
Le 08/08/2016 à 05:26, Ian Collins a écrit : >> And that takes tens of thousands of lines of of code? > > Who cares? Do you care how many lines of code it takes to open a web page? This is the root of the degrading of our profession into a a "click happy, turn off your brain" profession. Why bother at all with producing cleanly written software? NOBODY CARES! Just click around, use whatever monstruosity is available and finish the job today instead of tomorrow! That is why the New York Times serves you malware in the ads pages it serves. Nobody checks anything any more, why bother? It is impossible to check anything. Hidden in that 20 000 lines configure script ANY virus could be hidden safely since nobody will check that. Note that the machine infected by a rogue CONFIGURE script could be completely fucked up since they run very often with root privileges. Since configure scripts are plain text, inserting a back door or a trojan there is MUCH easier than patching an executable and requires less skills.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-08 21:13 +1200 |
| Message-ID | <e0r0q6Fia2rU1@mid.individual.net> |
| In reply to | #91927 |
On 08/ 8/16 08:26 PM, jacobnavia wrote: > > It is impossible to check anything. Hidden in that 20 000 lines > configure script ANY virus could be hidden safely since nobody will > check that. Note that the machine infected by a rogue CONFIGURE script > could be completely fucked up since they run very often with root > privileges. There is never any need to run a configure script as root. > Since configure scripts are plain text, inserting a back > door or a trojan there is MUCH easier than patching an executable and > requires less skills. It would also be much easier to spot... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-08 10:41 +0100 |
| Message-ID | <no9k3q$t00$1@dont-email.me> |
| In reply to | #91930 |
On 08/08/2016 10:13, Ian Collins wrote: > On 08/ 8/16 08:26 PM, jacobnavia wrote: >> >> It is impossible to check anything. Hidden in that 20 000 lines >> configure script ANY virus could be hidden safely since nobody will >> check that. Note that the machine infected by a rogue CONFIGURE script >> could be completely fucked up since they run very often with root >> privileges. > > There is never any need to run a configure script as root. > >> Since configure scripts are plain text, inserting a back >> door or a trojan there is MUCH easier than patching an executable and >> requires less skills. > > It would also be much easier to spot... Who's going to bother reading it? >
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-08 12:00 +0200 |
| Message-ID | <no9l8k$vt5$1@dont-email.me> |
| In reply to | #91930 |
Le 08/08/2016 à 11:13, Ian Collins a écrit : > On 08/ 8/16 08:26 PM, jacobnavia wrote: >> >> It is impossible to check anything. Hidden in that 20 000 lines >> configure script ANY virus could be hidden safely since nobody will >> check that. Note that the machine infected by a rogue CONFIGURE script >> could be completely fucked up since they run very often with root >> privileges. > > There is never any need to run a configure script as root. > This BLLATANTLY NOT TRUE! How will you install in /usr/local or in /usr/bin ??? OF COURSE you need toç be root to run the install script >> Since configure scripts are plain text, inserting a back >> door or a trojan there is MUCH easier than patching an executable and >> requires less skills. > > It would also be much easier to spot... > Sure, after you have READ AND UNDERSTOOD 20 000 lines of computer generated code for each package you install. Now, to avoid this you would have to furnish an md5 signature, that you would have to update each time you add a single space to that script. And you would have to geta machine for OS X since the line separator is different than in windows (another machine you would have to get) and in linux (yet another line ending convention).
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-08 22:07 +1200 |
| Message-ID | <e0r3u6Fj0t1U1@mid.individual.net> |
| In reply to | #91936 |
On 08/ 8/16 10:00 PM, jacobnavia wrote: > Le 08/08/2016 à 11:13, Ian Collins a écrit : >> On 08/ 8/16 08:26 PM, jacobnavia wrote: >>> >>> It is impossible to check anything. Hidden in that 20 000 lines >>> configure script ANY virus could be hidden safely since nobody will >>> check that. Note that the machine infected by a rogue CONFIGURE script >>> could be completely fucked up since they run very often with root >>> privileges. >> >> There is never any need to run a configure script as root. >> > This BLLATANTLY NOT TRUE! NO IT IS NOT! > How will you install in /usr/local or in /usr/bin ??? By running "sudo make install". If you install in /usr/bin, you deserve all the pain you bring upon yourself. >>> Since configure scripts are plain text, inserting a back >>> door or a trojan there is MUCH easier than patching an executable and >>> requires less skills. >> >> It would also be much easier to spot... >> > Sure, after you have READ AND UNDERSTOOD 20 000 lines of computer > generated code for each package you install. > > Now, to avoid this you would have to furnish an md5 signature, that you > would have to update each time you add a single space to that script. Most packages do provide md5 or sha sums. > And you would have to geta machine for OS X since the line separator is > different than in windows (another machine you would have to get) and in > linux (yet another line ending convention). I don't see the relevance, but OS-X uses Unix line endings. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-08 12:57 +0200 |
| Message-ID | <no9oii$amf$1@dont-email.me> |
| In reply to | #91936 |
On 08/08/16 12:00, jacobnavia wrote: > Le 08/08/2016 à 11:13, Ian Collins a écrit : >> On 08/ 8/16 08:26 PM, jacobnavia wrote: >>> >>> It is impossible to check anything. Hidden in that 20 000 lines >>> configure script ANY virus could be hidden safely since nobody will >>> check that. Note that the machine infected by a rogue CONFIGURE script >>> could be completely fucked up since they run very often with root >>> privileges. >> >> There is never any need to run a configure script as root. >> > > > This BLLATANTLY NOT TRUE! > > How will you install in /usr/local or in /usr/bin ??? > > > OF COURSE you need toç be root to run the install script > The configuration script is not the install script. In the typical build process, you run ./configure as a user. You might want additional options here. For gcc, for example, there are a number of commonly-used options such as your choice of target (for cross-compiling), your choice of languages (do you really want Fortran, Go, Ada, Java, etc.?), and your choice of directories and prefixes for the final programs. Then you run make as the same user, to do the actual build. You might want a "-j" option here for parallel builds. Finally, you have make install either as a user (for user-local installation), or as root (perhaps with "sudo") to install in /usr/local (typically) or /usr/bin (which is rarely a good idea). If you are paranoid, or have reason to suspect malware, and are not content with the usual md5 or sha checksum verification, then you can do all these steps as a user. And on *nix, it's no problem creating a new user for the purpose which (on most setups) has no write access to other users' files and thus very limited damage potential.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-08-08 18:12 +0100 |
| Message-ID | <87mvknchi1.fsf@gmail.com> |
| In reply to | #91936 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > This BLLATANTLY NOT TRUE! > > How will you install in /usr/local or in /usr/bin ??? > > > OF COURSE you need toç be root to run the install script ./configure is not the install script. And calm down. Sheesh.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-08 21:25 +1200 |
| Message-ID | <e0r1gfFigp4U1@mid.individual.net> |
| In reply to | #91927 |
On 08/ 8/16 08:26 PM, jacobnavia wrote: > Le 08/08/2016 à 05:26, Ian Collins a écrit : >>> And that takes tens of thousands of lines of of code? >> >> Who cares? Do you care how many lines of code it takes to open a web page? > > This is the root of the degrading of our profession into a a "click > happy, turn off your brain" profession. > > Why bother at all with producing cleanly written software? Because an autoconf configure script is machine generated! If you or Bart don't like what autoconf produces, write something better. If it is so bad, why hasn't it died and been replaced in the 30 years it has been in use? > NOBODY CARES! So do you read and check every bit of software you use? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-08 02:57 -0700 |
| Message-ID | <357a702d-32bb-404a-b37a-bd7077024854@googlegroups.com> |
| In reply to | #91932 |
On Monday, August 8, 2016 at 10:25:43 AM UTC+1, Ian Collins wrote: > On 08/ 8/16 08:26 PM, jacobnavia wrote: > > Le 08/08/2016 à 05:26, Ian Collins a écrit : > >>> And that takes tens of thousands of lines of of code? > >> > >> Who cares? Do you care how many lines of code it takes to open a web page? > > > > This is the root of the degrading of our profession into a a "click > > happy, turn off your brain" profession. > > > > Why bother at all with producing cleanly written software? > > Because an autoconf configure script is machine generated! If you or > Bart don't like what autoconf produces, write something better. If it > is so bad, why hasn't it died and been replaced in the 30 years it has > been in use? > I was reading scientific paper someone wrote on comparing DNA sequence alignment tools. The author had the honesty to admit that there were some tools he was unable to test due to difficulties with the install arrangements. It's a nightmare situation. However writing your own install system is likely to simply make the situation worse. We employ someone who writes installers for our products. That's virtually his fulltime job. Not quite, but it seems like every few days he's pulled off the main project to do some work on the installers, I haven't kept a log (I'm not his manager) but I'd guess at least 50% of his time is spent on these installers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-07 13:28 -0700 |
| Message-ID | <ln37mgxr0z.fsf@kst-u.example.com> |
| In reply to | #91847 |
BartC <bc@freeuk.com> writes:
> On 07/08/2016 10:53, Ian Collins wrote:
[...]
>> ./configure; make
>>
>> Now that's one massive hoop...
>
> On my machine that doesn't work. Because it's designed to be meaningful
> only on Linux or something that emulates Linux.
Unix, not just Linux. I'm fairly sure the "configure;make;make install"
mechanism is older than Linux.
> Getting that sorted /is/ quite a big hoop.
>
> But even if it worked**, the question is WHY? What on earth does it do
> that absolutely REQUIRES 20,000 lines of scripting code? Is there no one
> willing to simplify it?
>
> If everyone ignores these issues, then sooner or later we will need
> 200,000 lines of scripting code (piling up layer upon layer) and no one
> on the planet will know what it all does.
So you object to running a 20,000-line script.
After the script runs, you have to run a C compiler, either directly,
via a "make" command, or something else. Do you expect everyone who
uses a C compiler to understand how it works, or to care how many lines
of code had to be written to implement it?
From my point of view (as a Unix/Linux user), the conventional
"configure;make;make install" sequence is trivial; I can type a one-line
command to build and install a software package from source.
The fact that it's not as easy for Windows users is certainly a valid
issue. In some cases, it might be because the authors of the software
package you're trying to install do not care about Windows. (Conversely,
some software packages developed for Windows are difficult or impossible
to install on Unix or Linux.)
The size and complexity of a typical configure script are not an issue
*when it works*. When it doesn't, I fail to see how complaining about
it here will do anyone any good.
You've complained repeatedly about the difficulty of installing Clang on
Windows. Have you considered communicating with the Clang maintainers?
--
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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-07 05:42 -0700 |
| Message-ID | <11a9c3f4-2ef2-42b2-92a1-37868659f5c8@googlegroups.com> |
| In reply to | #91844 |
Bartc wrote: > Probably everyone else is happy to jump through all > those hoops (perhaps because they've always had to do it > and think that's how it must be). I'm not! I used to think as you do. But I was wrong, and you are too. Consider what you're doing, Bart: You're turning your back on man- years worth of debugged software because you don't like the package they come in. You complain the wrapping is too hard to open. I believe a tweak to that attitude is in order because what you're receiving is a gift that requires a one time knowledge increase on how to set up the compile environment. It's a small price to pay for what you get in return. Best regards, Rick C. Hodgin
[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