Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #129717 > unrolled thread
| Started by | bartc <bc@freeuk.com> |
|---|---|
| First post | 2018-04-25 16:21 +0100 |
| Last post | 2018-04-27 19:37 +0100 |
| Articles | 4 on this page of 104 — 27 participants |
Back to article view | Back to comp.lang.c
gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 16:21 +0100
gcc_centric C code Chad <cdalten@gmail.com> - 2018-04-25 08:34 -0700
Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-25 16:41 +0100
Re: gcc_centric C code Spiros Bousbouras <spibou@gmail.com> - 2018-04-25 16:19 +0000
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 18:02 +0100
Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-25 17:15 +0000
Re: gcc_centric C code Robert Wessel <robertwessel2@yahoo.com> - 2018-04-25 12:33 -0500
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 20:51 +0100
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 13:01 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 21:21 +0100
Re: gcc_centric C code jameskuyper@verizon.net - 2018-04-25 13:45 -0700
Re: gcc_centric C code Spiros Bousbouras <spibou@gmail.com> - 2018-04-25 17:20 +0000
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 10:30 -0700
Re: gcc_centric C code Robert Wessel <robertwessel2@yahoo.com> - 2018-04-25 12:35 -0500
Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 10:54 -0700
Re: gcc_centric C code Philipp Klaus Krause <pkk@spth.de> - 2018-04-25 20:27 +0200
Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 12:38 -0700
Re: gcc_centric C code Robert Wessel <robertwessel2@yahoo.com> - 2018-04-25 19:53 -0500
Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 18:13 -0700
Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-26 15:16 +0000
Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 08:17 -0700
Re: gcc_centric C code Philipp Klaus Krause <pkk@spth.de> - 2018-04-26 08:03 +0200
Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-26 14:30 +0000
Re: gcc_centric C code jameskuyper@verizon.net - 2018-04-26 08:26 -0700
Re: gcc_centric C code Philipp Klaus Krause <pkk@spth.de> - 2018-04-26 19:04 +0200
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 07:48 +1200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 21:08 +0100
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 08:18 +1200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 21:44 +0100
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 09:01 +1200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 23:16 +0100
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 10:27 +1200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 23:48 +0100
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 20:41 +1200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 11:51 +0100
Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-28 07:32 +1200
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-28 04:34 -0700
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 23:05 -0700
Re: gcc_centric C code jacobnavia <jacob@jacob.remcomp.fr> - 2018-04-27 00:52 +0200
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-26 16:23 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-28 11:24 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-28 01:42 +0100
Re: gcc_centric C code Dan Purgert <dan@djph.net> - 2018-04-26 21:40 +0000
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 23:34 +0100
Re: gcc_centric C code "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-04-26 14:13 -0700
Re: gcc_centric C code "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-04-26 14:16 -0700
Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 08:08 -0700
Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-27 09:11 -0700
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-27 09:26 -0700
Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 09:49 -0700
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 12:31 -0700
Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-25 20:13 +0000
Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 13:50 -0700
Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-25 18:02 +0000
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-25 22:39 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 18:36 +0100
Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-25 23:15 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 02:02 +0100
Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 18:28 -0700
Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-26 11:45 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 14:53 +0100
Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-26 23:38 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 00:31 +0100
Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-27 00:47 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 02:28 +0100
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-04-27 03:44 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-05-03 13:57 +0100
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 11:02 -0700
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 11:07 -0700
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 11:13 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-05-03 19:50 +0100
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 13:37 -0700
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 13:44 -0700
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 10:25 -0700
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 07:01 -0700
Re: Clearly everyone else likes to do things the hard way Noob <root@127.0.0.1> - 2018-04-26 14:51 +0200
Re: Clearly everyone else likes to do things the hard way mark.bluemel@gmail.com - 2018-04-26 07:09 -0700
Re: Clearly everyone else likes to do things the hard way gazelle@shell.xmission.com (Kenny McCormack) - 2018-04-26 17:05 +0000
Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-26 18:38 +0100
Re: Clearly everyone else likes to do things the hard way 1alvinalbrecht1@gmail.com - 2018-04-26 11:34 -0700
Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-26 21:36 +0100
Re: Clearly everyone else likes to do things the hard way C W Rose <cwr@seckford.org> - 2018-04-27 19:23 +0100
Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-28 14:34 +0100
Re: Clearly everyone else likes to do things the hard way Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-28 10:32 -0700
Re: Clearly everyone else likes to do things the hard way supercat@casperkitty.com - 2018-04-30 10:16 -0700
Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-30 19:41 +0100
Re: Clearly everyone else likes to do things the hard way supercat@casperkitty.com - 2018-04-30 12:11 -0700
Re: Clearly everyone else likes to do things the hard way scott@slp53.sl.home (Scott Lurndal) - 2018-04-30 19:14 +0000
Re: Clearly everyone else likes to do things the hard way scott@slp53.sl.home (Scott Lurndal) - 2018-04-30 19:12 +0000
Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-30 21:19 +0100
Re: Clearly everyone else likes to do things the hard way Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 19:23 -0700
Re: Clearly everyone else likes to do things the hard way Philipp Klaus Krause <pkk@spth.de> - 2018-04-26 19:45 +0200
Re: gcc_centric C code luser droog <luser.droog@gmail.com> - 2018-04-25 21:56 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 11:06 +0100
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 11:27 +0100
Re: gcc_centric C code antispam@math.uni.wroc.pl - 2018-04-26 17:00 +0000
Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-04-25 09:26 -0700
Re: gcc_centric C code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-26 12:39 +0000
Re: gcc_centric C code gazelle@shell.xmission.com (Kenny McCormack) - 2018-04-26 13:09 +0000
Re: gcc_centric C code Wouter Verhelst <w@uter.be> - 2018-04-26 13:26 +0200
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 18:03 +0100
Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 14:32 -0700
Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 09:41 -0700
Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 19:37 +0100
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-26 18:03 +0100 |
| Message-ID | <bDnEC.72558$I77.46220@fx44.am4> |
| In reply to | #129798 |
On 26/04/2018 12:26, Wouter Verhelst wrote: > On 25-04-18 17:21, bartc wrote: >> All this I find quite typical of open source C code. > > IME, provided your compiler is recognized by autoconf (which generates > the configure script), My private compiler won't be. But why should it; it's just C code, right? The whole point of everyone writing in a standardised language is so that you can apply any C compiler to any program. > this all works like a breeze. I have to run "./configure". That doesn't work under Windows unless I import MSYS, MSYS2 or CYGWIN. And even then there might be enough reasons it doesn't work that other solutions, usually involving VS (and usually not working IME) need to be provided for Windows. That doesn't sound a 'breeze' to me. Because I don't use any of these complicated configuration tools, my C programs really CAN be breeze to build. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-26 14:32 -0700 |
| Message-ID | <124bc8b0-0bf4-4e0b-8430-78779d404fa9@googlegroups.com> |
| In reply to | #129798 |
On Thursday, April 26, 2018 at 9:08:09 AM UTC-7, Wouter Verhelst wrote: > On 25-04-18 17:21, bartc wrote: > > These are some observations about the difficulties of getting C source > > code to compile, if you try and do it outside the confines of a > > preferred compiler and build system. > > > > I took one github C project and tried to compile all the 48 C files in > > one subdirectory, but without using makefiles or taking any config > > steps. These are the results trying various Windows C compilers: > > > > gcc 47 files compiled successfully out of 48 > > Tiny C 40 files > > Pelles C 32 files > > lccwin 17 files > > DMC 24 files > > MSVC 38 files > > bcc (mine) 36 files (after disabling a code-gen bug) > > > > The one problem file for gcc was a missing header that I couldn't find > > anywhere. > > > > Now, maybe this needs to have some configuration to build some config.h > > Yes. > > In such projects, usually you run "./configure", which detects whether > you have installed every required package, and detects which optional > packages you've installed. > > The result is then written to a config.h file in the form of #define lines. > > [...] > > #ifdef STDC_HEADERS > > # include <stdlib.h> > > # include <stddef.h> > > #else > > # ifdef HAVE_STDLIB_H > > This would be defined in config.h or with a -D parameter in the Makefile. > > > # include <stdlib.h> > > # endif > > #endif > > > > #ifdef HAVE_ALLOCA_H > > Same. > > > # include <alloca.h> > > #elif !defined alloca > > # ifdef __GNUC__ > > # define alloca __builtin_alloca > > # elif defined _AIX > > # define alloca __alloca > > # elif defined _MSC_VER > > # include <malloc.h> > > # define alloca _alloca > > # elif !defined HAVE_ALLOCA > > # ifdef __cplusplus > > extern "C" > > # endif > > void *alloca (size_t); > > # endif > > #endif > > > > --------------- > > The problem was that alloca() declaration, that uses size_t, because the > > needed headers are included after this code. This doesn't affect gcc or > > MSVC because they have their own #elif blocks so this isn't seen. > > > > All this I find quite typical of open source C code. > > IME, provided your compiler is recognized by autoconf (which generates > the configure script), this all works like a breeze. I won't ask J Burns how any part of Owl's body tastes no matter how regularly J Burns smooches it. Do you believe the bullshit J Burns is spewing? I'm getting a lot of killed files. I'm guessing the circus is in its brain damage mode again. Yawn. Same old brain-dead trolls. He pretends that he uses ChromeOS, while of course he never used it on the fly and actually tried it. You do realize that the massive floods ending up in multiple groups started out in COLA, right? I noted specific examples of J Burns falsely attributing someone else's words to me, flooding every group I post to, etc. His response: to blame me. Are you being stupid on purpose? -- "You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention" Steve Carroll, making the dumbest comment ever uttered.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-27 09:41 -0700 |
| Message-ID | <kfnwowslhzy.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #129717 |
bartc <bc@freeuk.com> writes: > These are some observations about the difficulties of getting C source > code to compile, if you try and do it outside the confines of a > preferred compiler and build system. > > I took one github C project and tried to compile all the 48 C files in > one subdirectory, but without using makefiles or taking any config > steps. These are the results trying various Windows C compilers: > > gcc 47 files compiled successfully out of 48 > Tiny C 40 files > Pelles C 32 files > lccwin 17 files > DMC 24 files > MSVC 38 files > bcc (mine) 36 files (after disabling a code-gen bug) > > The one problem file for gcc was a missing header that I couldn't find > anywhere. > > Now, maybe this needs to have some configuration to build some > config.h which will magically make it all work, or maybe not all files > are relevant for a particular config. > > But if you are using a very non-mainstream and bare compiler like > mine, then that is unlikely to make a difference. > > The fact is, that even after bunches of #ifdefs to cater for GNUC and > MSCVER and whatever, there are still difficulties in getting code to > compile. > > Among the problems I had to solve to get to my 36/48, was the use of > __func__, something that doesn't seem to be in the C standard, and > appears to be a predefined macro to give the current function > name. OK, I had to implement that (but how many dozens of such ad-hoc > extensions are there?). > > Another, was not recognising 'size_t', which was due to a block of > code like this: > > #ifdef STDC_HEADERS > # include <stdlib.h> > # include <stddef.h> > #else > # ifdef HAVE_STDLIB_H > # include <stdlib.h> > # endif > #endif > > #ifdef HAVE_ALLOCA_H > # include <alloca.h> > #elif !defined alloca > # ifdef __GNUC__ > # define alloca __builtin_alloca > # elif defined _AIX > # define alloca __alloca > # elif defined _MSC_VER > # include <malloc.h> > # define alloca _alloca > # elif !defined HAVE_ALLOCA > # ifdef __cplusplus > extern "C" > # endif > void *alloca (size_t); > # endif > #endif > > The problem was that alloca() declaration, that uses size_t, because > the needed headers are included after this code. This doesn't affect > gcc or MSVC because they have their own #elif blocks so this isn't > seen. > > All this I find quite typical of open source C code. It is > soul-destroying if you're trying to get an implementation to work, and > that fact that other compilers including MVSC can also have problems, > is not much comfort. Yes, it is quite inconsiderate of open source developers to put the needs and expectations of tens of thousands of other developers ahead of what you want and how you think things should be done. What could they have been thinking?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-27 19:37 +0100 |
| Message-ID | <J5KEC.23637$Ze.22260@fx39.am4> |
| In reply to | #129861 |
On 27/04/2018 17:41, Tim Rentsch wrote:
> bartc <bc@freeuk.com> writes:
>> All this I find quite typical of open source C code.
> Yes, it is quite inconsiderate of open source developers to put the
> needs and expectations of tens of thousands of other developers
> ahead of what you want and how you think things should be done.
> What could they have been thinking?
I understand. Striving to simplify bloated, complex, error prone build
systems, heavily dependent on dozens of utilities beyond a
compiler/linker, is NEVER worth doing, and it is selfish of someone to
even think that could be of benefit.
(God forbid some of those 10s of 1000s of developers could lose their
jobs because there is less work to do.)
30,000-line scripts to figure out the input options to a compiler? Not
enough! They ought to be 300,000 lines at least to be taken seriously.
(End of sarcasm in case you hadn't noticed.)
The subject is gcc-centricity. By using non-gcc compilers, I found this
issue in ./src/lib/xpost_compat.c of that test project, on line 217:
HCRYPTPROV provider = NULL;
HCRYPTPROV is defined via two nested typededs as unsigned long long. And
gcc (5.1.0 at least) defines NULL as 0LL. So this passes with no comment.
But other compilers might define NULL as (void*)0, which results in a
warning or error, that could happen when someone else is building it,
years later and in a different country. Because people rely too much on gcc.
(The real problem is that HCRYPTPROV is an opaque type which could
equally be pointer or integer - it's defined on top of ULONG_PTR which
is defined on top of unsigned long long. So it should either be
initialised with zero, or via a cast, or a special NULL version for
HCRYPTPROV should be defined. The issue would not be a malfunctioning
program, but an unexpected build error.)
--
bartc
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web