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 | 20 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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-27 08:17 -0700 |
| Message-ID | <kfna7ton0g4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #129761 |
Keith Thompson <kst-u@mib.org> writes: > Robert Wessel <robertwessel2@yahoo.com> writes: > >> On Wed, 25 Apr 2018 20:27:32 +0200, Philipp Klaus Krause <pkk@spth.de> >> wrote: >> >>> Am 25.04.2018 um 19:54 schrieb Keith Thompson: >>> >>>> A very minor point: values yielded by __func__ can be compared for >>>> pointer equality. (I've never seen code that relies on this.) >>> >>> The interaction of that with inline is problematic. >> >> Why? Why should it be any different than any inlined function that >> contains a static data item? All inlined copies, as well as a >> separately built copy (assuming it exists) would use the same (static) >> item. > > N1570 6.7.4p7: > > Any function with internal linkage can be an inline function. For a > function with external linkage, the following restrictions apply: > [snip] > It is unspecified whether a call to the function uses the inline > definition or the external definition. > > with a footnote: > > Since an inline definition is distinct from the corresponding > external definition and from any other corresponding inline > definitions in other translation units, all corresponding objects > with static storage duration are also distinct in each of the > definitions. That doesn't make it problematic. Just the opposite: the inline-only function and the external-providing function are different functions (the two definitions are independent), and they have different values for the two internal variables.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-04-26 08:03 +0200 |
| Message-ID | <pbrq2s$r4b$1@solani.org> |
| In reply to | #129759 |
Am 26.04.2018 um 02:53 schrieb Robert Wessel: > On Wed, 25 Apr 2018 20:27:32 +0200, Philipp Klaus Krause <pkk@spth.de> > wrote: > >> Am 25.04.2018 um 19:54 schrieb Keith Thompson: >>> >>> A very minor point: values yielded by __func__ can be compared for >>> pointer equality. (I've never seen code that relies on this.) >>> >> >> The interaction of that with inline is problematic. > > > Why? Why should it be any different than any inlined function that > contains a static data item? All inlined copies, as well as a > separately built copy (assuming it exists) would use the same (static) > item. > The one problematic use case is comparing pointers to static objects (as can be seen from the reply by Keith). Note that static objects in inline functions need to be const (6.7.4 in N1570 / C11 / C17), so there will be no problems with the value of such objects. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Nick Bowler <nbowler@draconx.ca> |
|---|---|
| Date | 2018-04-26 14:30 +0000 |
| Message-ID | <pbsnq8$mqn$1@dont-email.me> |
| In reply to | #129767 |
On Thu, 26 Apr 2018 08:03:08 +0200, Philipp Klaus Krause wrote: > Am 26.04.2018 um 02:53 schrieb Robert Wessel: >> On Wed, 25 Apr 2018 20:27:32 +0200, Philipp Klaus Krause <pkk@spth.de> >> wrote: >> >>> Am 25.04.2018 um 19:54 schrieb Keith Thompson: >>>> >>>> A very minor point: values yielded by __func__ can be compared for >>>> pointer equality. (I've never seen code that relies on this.) >>>> >>> >>> The interaction of that with inline is problematic. >> >> >> Why? Why should it be any different than any inlined function that >> contains a static data item? All inlined copies, as well as a >> separately built copy (assuming it exists) would use the same (static) >> item. >> > > The one problematic use case is comparing pointers to static objects (as > can be seen from the reply by Keith). > Note that static objects in inline functions need to be const (6.7.4 in > N1570 / C11 / C17), so there will be no problems with the value of such > objects. The restrictions you are referring to is 6.7.4p2 and only apply to *inline definitions*. "Inline definition" is defined in 6.7.4p7 and refers to the special case where the function has external linkage, *all* the file-scope declarations of the function in the translation unit have the inline specifier and *none* of them have the extern specifier. In every other case, inline functions may refer to any kind of object just like any other kind of function can.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2018-04-26 08:26 -0700 |
| Message-ID | <e70a08dd-1464-42c9-b3f6-d39f56015997@googlegroups.com> |
| In reply to | #129767 |
On Thursday, April 26, 2018 at 2:03:17 AM UTC-4, Philipp Klaus Krause wrote: > Am 26.04.2018 um 02:53 schrieb Robert Wessel: > > On Wed, 25 Apr 2018 20:27:32 +0200, Philipp Klaus Krause <pkk@spth.de> > > wrote: > > > >> Am 25.04.2018 um 19:54 schrieb Keith Thompson: > >>> > >>> A very minor point: values yielded by __func__ can be compared for > >>> pointer equality. (I've never seen code that relies on this.) > >>> > >> > >> The interaction of that with inline is problematic. > > > > > > Why? Why should it be any different than any inlined function that > > contains a static data item? All inlined copies, as well as a > > separately built copy (assuming it exists) would use the same (static) > > item. > > > > The one problematic use case is comparing pointers to static objects (as > can be seen from the reply by Keith). > Note that static objects in inline functions need to be const (6.7.4 in > N1570 / C11 / C17), so there will be no problems with the value of such > objects. 123456789012345678901234567890123456789012345678901234567890123456789012 That's only true for inline definitions, but even for them, since __func__ is defined as an array of const char, it's definition doesn't violate the first part of 6.7.4p3, and as it has block scope, it has no linkage, so use of __func__ within such a function doesn't violate the second part of 6.7.4p3. What do you consider problematic about it?
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-04-26 19:04 +0200 |
| Message-ID | <pbt0rm$m1g$1@solani.org> |
| In reply to | #129795 |
Am 26.04.2018 um 17:26 schrieb jameskuyper@verizon.net: > On Thursday, April 26, 2018 at 2:03:17 AM UTC-4, Philipp Klaus Krause wrote: >> Am 26.04.2018 um 02:53 schrieb Robert Wessel: >>> On Wed, 25 Apr 2018 20:27:32 +0200, Philipp Klaus Krause <pkk@spth.de> >>> wrote: >>> >>>> Am 25.04.2018 um 19:54 schrieb Keith Thompson: >>>>> >>>>> A very minor point: values yielded by __func__ can be compared for >>>>> pointer equality. (I've never seen code that relies on this.) >>>>> >>>> >>>> The interaction of that with inline is problematic. >>> >>> >>> Why? Why should it be any different than any inlined function that >>> contains a static data item? All inlined copies, as well as a >>> separately built copy (assuming it exists) would use the same (static) >>> item. >>> >> >> The one problematic use case is comparing pointers to static objects (as >> can be seen from the reply by Keith). >> Note that static objects in inline functions need to be const (6.7.4 in >> N1570 / C11 / C17), so there will be no problems with the value of such >> objects. > 123456789012345678901234567890123456789012345678901234567890123456789012 > That's only true for inline definitions, but even for them, since > __func__ is defined as an array of const char, it's definition doesn't > violate the first part of 6.7.4p3, and as it has block scope, it has no > linkage, so use of __func__ within such a function doesn't violate the > second part of 6.7.4p3. What do you consider problematic about it? > "Problematic" in (the probably rather contrieved) case of someone wanting to identify functions by the values of pointers to some static members in them. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-27 07:48 +1200 |
| Message-ID | <fkeoodF36cfU3@mid.individual.net> |
| In reply to | #129804 |
On 04/27/2018 05:04 AM, Philipp Klaus Krause wrote: > 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. Why wouldn't it be recognised? Autoconf just uses the compiler (which you can identify with "CC=<your compiler>" to compile test code snippets. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-26 21:08 +0100 |
| Message-ID | <6lqEC.16239$9t.395@fx26.am4> |
| In reply to | #129816 |
On 26/04/2018 20:48, Ian Collins wrote:
> On 04/27/2018 05:04 AM, Philipp Klaus Krause wrote:
>> 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.
>
> Why wouldn't it be recognised? Autoconf just uses the compiler (which
> you can identify with "CC=<your compiler>" to compile test code snippets.
If I look at the 18,322-line configure file for CPython in github, then
there are hundreds of references to gcc, a lighter sprinkling of icc,
but remarkably few references to my compiler.
There is also this interesting snippet at line 4155:
int
main ()
{
#ifndef __GNUC__
choke me
#endif
;
return 0;
}
Apart from that, there are all the #ifdefs for __GNUC__ and MSV_VER you
find in source code. It's the #elif at the end of that chain of
conditional blocks (or worse, just #endif) that can be problematical.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-27 08:18 +1200 |
| Message-ID | <fkeqg5F36cfU4@mid.individual.net> |
| In reply to | #129817 |
On 04/27/2018 08:08 AM, bartc wrote: > On 26/04/2018 20:48, Ian Collins wrote: >> On 04/27/2018 05:04 AM, Philipp Klaus Krause wrote: >>> 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. >> >> Why wouldn't it be recognised? Autoconf just uses the compiler (which >> you can identify with "CC=<your compiler>" to compile test code snippets. > > If I look at the 18,322-line configure file for CPython in github, then > there are hundreds of references to gcc, a lighter sprinkling of icc, > but remarkably few references to my compiler. Did you actually read what I wrote? How do you think I ported numerous Linux centric open source projects to Solaris building with Sun's compilers? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-26 21:44 +0100 |
| Message-ID | <hSqEC.92030$Xa4.723@fx29.am4> |
| In reply to | #129818 |
On 26/04/2018 21:18, Ian Collins wrote: > On 04/27/2018 08:08 AM, bartc wrote: >> On 26/04/2018 20:48, Ian Collins wrote: >>> On 04/27/2018 05:04 AM, Philipp Klaus Krause wrote: >>>> 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. >>> >>> Why wouldn't it be recognised? Autoconf just uses the compiler (which >>> you can identify with "CC=<your compiler>" to compile test code >>> snippets. >> >> If I look at the 18,322-line configure file for CPython in github, then >> there are hundreds of references to gcc, a lighter sprinkling of icc, >> but remarkably few references to my compiler. > > Did you actually read what I wrote? How do you think I ported numerous > Linux centric open source projects to Solaris building with Sun's > compilers? Was that with the 'choke me' message for non-GNUC users in the middle of the configure file? Anyway I don't care about other people's gigantic projects; they can use whatever systems they like. I care about the ones /I/ want to build where this stuff is forced down my throat. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-27 09:01 +1200 |
| Message-ID | <fket0dF36cfU5@mid.individual.net> |
| In reply to | #129820 |
On 04/27/2018 08:44 AM, bartc wrote: > On 26/04/2018 21:18, Ian Collins wrote: >> On 04/27/2018 08:08 AM, bartc wrote: >>> On 26/04/2018 20:48, Ian Collins wrote: >>>> On 04/27/2018 05:04 AM, Philipp Klaus Krause wrote: >>>>> 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. >>>> >>>> Why wouldn't it be recognised? Autoconf just uses the compiler (which >>>> you can identify with "CC=<your compiler>" to compile test code >>>> snippets. >>> >>> If I look at the 18,322-line configure file for CPython in github, then >>> there are hundreds of references to gcc, a lighter sprinkling of icc, >>> but remarkably few references to my compiler. >> >> Did you actually read what I wrote? How do you think I ported numerous >> Linux centric open source projects to Solaris building with Sun's >> compilers? > > Was that with the 'choke me' message for non-GNUC users in the middle of > the configure file? > > Anyway I don't care about other people's gigantic projects; they can use > whatever systems they like. > > I care about the ones /I/ want to build where this stuff is forced down > my throat. You don't care to read what people write ether, do you? Just as a quick experiment to see how hard it is to build CPython on something other than Linux without gcc: export CC=/opt/OracleDeveloperStudio12.6/bin/cc export CPP="/opt/OracleDeveloperStudio12.6/bin/cc -E" ./configure --without-gcc --prefix=/opt/local --enable-optimizations make -J 8 make install /opt/local/bin/python3.8 --version Python 3.8.0a0 ls -l /opt/local/bin/python3.8 -rwxr-xr-x 2 root root 3427860 Apr 27 08:54 /opt/local/bin/python3.8 Wow, that was so hard... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-26 23:16 +0100 |
| Message-ID | <BcsEC.25942$ga6.7856@fx24.am4> |
| In reply to | #129821 |
On 26/04/2018 22:01, Ian Collins wrote: > On 04/27/2018 08:44 AM, bartc wrote: >> On 26/04/2018 21:18, Ian Collins wrote: >>> On 04/27/2018 08:08 AM, bartc wrote: >>>> On 26/04/2018 20:48, Ian Collins wrote: >>>>> On 04/27/2018 05:04 AM, Philipp Klaus Krause wrote: >>>>>> 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. >>>>> >>>>> Why wouldn't it be recognised? Autoconf just uses the compiler (which >>>>> you can identify with "CC=<your compiler>" to compile test code >>>>> snippets. >>>> >>>> If I look at the 18,322-line configure file for CPython in github, then >>>> there are hundreds of references to gcc, a lighter sprinkling of icc, >>>> but remarkably few references to my compiler. >>> >>> Did you actually read what I wrote? How do you think I ported numerous >>> Linux centric open source projects to Solaris building with Sun's >>> compilers? >> >> Was that with the 'choke me' message for non-GNUC users in the middle of >> the configure file? >> >> Anyway I don't care about other people's gigantic projects; they can use >> whatever systems they like. >> >> I care about the ones /I/ want to build where this stuff is forced down >> my throat. > > You don't care to read what people write ether, do you? Just as a quick > experiment to see how hard it is to build CPython on something other > than Linux without gcc: > > export CC=/opt/OracleDeveloperStudio12.6/bin/cc > export CPP="/opt/OracleDeveloperStudio12.6/bin/cc -E" > ./configure --without-gcc --prefix=/opt/local --enable-optimizations > make -J 8 > make install > /opt/local/bin/python3.8 --version > Python 3.8.0a0 > ls -l /opt/local/bin/python3.8 > -rwxr-xr-x 2 root root 3427860 Apr 27 08:54 > /opt/local/bin/python3.8 > > Wow, that was so hard... Some questions: * How did you manage to do ./configure on that other machine? Or does it just work because, after all, they are both really Unix? * Do you try this on Windows? * What does that other compiler return for the value of __GNUC__? If not defined, how does it manage to avoid that trap in the middle of configure? * What macro does that cc compiler export as its identifier? CPython sources explicitly test for MS_WINDOWS, BORLANDC, WATCOMC, DJGPP, GNUC, SUNPROC_C, SGI, and SOLARIS among others. The fact is that on Windows, CPython can't be built with gcc, so they have to have a VS solution (which is even more problematic). The build process is just too complex. Another question: with whatever compiler was used on that other machine, do you think it worked perfectly the first time it was used to compile CPython, without the need to touch 'configure' at all or any part of the CPython sources? Or is it possible that what you are seeing represents a considerable amount of work to make it happen? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-27 10:27 +1200 |
| Message-ID | <fkf220Fi91uU1@mid.individual.net> |
| In reply to | #129826 |
On 04/27/2018 10:16 AM, bartc wrote: > On 26/04/2018 22:01, Ian Collins wrote: >> On 04/27/2018 08:44 AM, bartc wrote: >>> On 26/04/2018 21:18, Ian Collins wrote: >>>> On 04/27/2018 08:08 AM, bartc wrote: >>>>> On 26/04/2018 20:48, Ian Collins wrote: >>>>>> On 04/27/2018 05:04 AM, Philipp Klaus Krause wrote: >>>>>>> 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. >>>>>> >>>>>> Why wouldn't it be recognised? Autoconf just uses the compiler (which >>>>>> you can identify with "CC=<your compiler>" to compile test code >>>>>> snippets. >>>>> >>>>> If I look at the 18,322-line configure file for CPython in github, then >>>>> there are hundreds of references to gcc, a lighter sprinkling of icc, >>>>> but remarkably few references to my compiler. >>>> >>>> Did you actually read what I wrote? How do you think I ported numerous >>>> Linux centric open source projects to Solaris building with Sun's >>>> compilers? >>> >>> Was that with the 'choke me' message for non-GNUC users in the middle of >>> the configure file? >>> >>> Anyway I don't care about other people's gigantic projects; they can use >>> whatever systems they like. >>> >>> I care about the ones /I/ want to build where this stuff is forced down >>> my throat. >> >> You don't care to read what people write ether, do you? Just as a quick >> experiment to see how hard it is to build CPython on something other >> than Linux without gcc: >> >> export CC=/opt/OracleDeveloperStudio12.6/bin/cc >> export CPP="/opt/OracleDeveloperStudio12.6/bin/cc -E" >> ./configure --without-gcc --prefix=/opt/local --enable-optimizations >> make -J 8 >> make install >> /opt/local/bin/python3.8 --version >> Python 3.8.0a0 >> ls -l /opt/local/bin/python3.8 >> -rwxr-xr-x 2 root root 3427860 Apr 27 08:54 >> /opt/local/bin/python3.8 >> >> Wow, that was so hard... > > Some questions: > > * How did you manage to do ./configure on that other machine? Or does it > just work because, after all, they are both really Unix? > > * Do you try this on Windows? I don't have a Windows machine. > * What does that other compiler return for the value of __GNUC__? If not > defined, how does it manage to avoid that trap in the middle of configure? I don't care, I configured with "--without-gcc". > * What macro does that cc compiler export as its identifier? CPython > sources explicitly test for MS_WINDOWS, BORLANDC, WATCOMC, DJGPP, GNUC, > SUNPROC_C, SGI, and SOLARIS among others. > > The fact is that on Windows, CPython can't be built with gcc, so they > have to have a VS solution (which is even more problematic). The build > process is just too complex. That's Windows for you. You could just do what our developers with Windows desktops do and use Windows Subsystem for Linux (WSL). > Another question: with whatever compiler was used on that other machine, > do you think it worked perfectly the first time it was used to compile > CPython, without the need to touch 'configure' at all or any part of the > CPython sources? Why should it? That's not how the build system is designed. > Or is it possible that what you are seeing represents a considerable > amount of work to make it happen? Someone else's work, not mine. CPython is something called a "project" which has people called "maintainers". I suggest you familiarise yourself with those terms. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-26 23:48 +0100 |
| Message-ID | <lGsEC.12310$Pv4.1229@fx23.am4> |
| In reply to | #129827 |
On 26/04/2018 23:27, Ian Collins wrote:
> On 04/27/2018 10:16 AM, bartc wrote:
>> Or is it possible that what you are seeing represents a considerable
>> amount of work to make it happen?
>
> Someone else's work, not mine.
So it's possible that there were lots of problems just like I see.
(Out of interest, what happens when you compile that pcc64.c file I
linked to earlier [1] on that other machine, assuming it's 64-bit capable?
The highly complex build instructions are these:
* Compile pcc64.c to an executable with a C compiler
Example for gcc Linux:
gcc -m64 pcc64.c -opcc -lm
([1] http://home.freeuk.com/bcas/pcc64.c)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-27 20:41 +1200 |
| Message-ID | <fkg61mFi91uU2@mid.individual.net> |
| In reply to | #129830 |
On 04/27/2018 10:48 AM, bartc wrote: > On 26/04/2018 23:27, Ian Collins wrote: >> On 04/27/2018 10:16 AM, bartc wrote: > >>> Or is it possible that what you are seeing represents a considerable >>> amount of work to make it happen? >> >> Someone else's work, not mine. > > So it's possible that there were lots of problems just like I see. Problems long solved by the build system. > (Out of interest, what happens when you compile that pcc64.c file I > linked to earlier [1] on that other machine, assuming it's 64-bit capable? It breaks the current version of the compiler, an older version rejects it with 3101 warnings/errors. Mostly along the lines of "pcc64.c", line 2785: cannot use an address to initialize a field of a packed struct (#pragma pack) and "pcc64.c", line 16749: improper member use: mutable and "pcc64.c", line 3395: warning: initialization type mismatch -- Ian
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-27 11:51 +0100 |
| Message-ID | <LgDEC.29568$Hc3.19774@fx30.am4> |
| In reply to | #129845 |
On 27/04/2018 09:41, Ian Collins wrote:
> On 04/27/2018 10:48 AM, bartc wrote:
>> (Out of interest, what happens when you compile that pcc64.c file I
>> linked to earlier [1] on that other machine, assuming it's 64-bit
>> capable?
>
> It breaks the current version of the compiler, an older version rejects
> it with 3101 warnings/errors. Mostly along the lines of
>
> "pcc64.c", line 2785: cannot use an address to initialize a field of a
> packed struct (#pragma pack)
>
> and
>
> "pcc64.c", line 16749: improper member use: mutable
(Warning or error? And what's wrong with it? ('mutable' is a member of
an anonymous union.))
> and
>
> "pcc64.c", line 3395: warning: initialization type mismatch
OK, thanks. If I add as many options as I can find, I get roughly 2000
warnings (mostly about unused stuff), for example:
gcc -m64 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -Wshadow
-Wpointer-arith -Wcast-qual -Wmissing-prototypes -Wno-missing-braces
-std=c11 -D_GNU_SOURCE pcc64.c -opcc64.exe
but no errors. The pcc64.exe program is produced, and it will run,
giving a usage message.
What options did you use? (Pretty strict I would bet.)
With C compilers as I normally use them:
gcc (5.1.0 Windows) 0 warnings
Pelles C 500 warnings (unused labels, unreachable code)
lccwin 30 warnings
MSVC 3 warnings
Tiny C 0 warnings (don't know if it does warnings)
bcc --- (does not generate warnings)
gcc (4.4.2 Linux) 1 warning (overflow in numeric constant)
gcc (6.2.0 Linux) 4 warnings (printf argument mismatch)
DMC 23 warnings (possible unintended assignments)
It's nice to see how much in agreement C compilers can be about what
might be amiss in a program!
> It breaks the current version of the compiler
What do you mean by it breaks it?
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-28 07:32 +1200 |
| Message-ID | <fkhc61Fi91uU3@mid.individual.net> |
| In reply to | #129851 |
On 04/27/2018 10:51 PM, bartc wrote:
> On 27/04/2018 09:41, Ian Collins wrote:
>> On 04/27/2018 10:48 AM, bartc wrote:
>
>>> (Out of interest, what happens when you compile that pcc64.c file I
>>> linked to earlier [1] on that other machine, assuming it's 64-bit
>>> capable?
>>
>> It breaks the current version of the compiler, an older version rejects
>> it with 3101 warnings/errors. Mostly along the lines of
>>
>> "pcc64.c", line 2785: cannot use an address to initialize a field of a
>> packed struct (#pragma pack)
>>
>> and
>>
>> "pcc64.c", line 16749: improper member use: mutable
>
> (Warning or error? And what's wrong with it? ('mutable' is a member of
> an anonymous union.))
C99 doesn't have anonymous unions... That compiler's default mode is
roughly equivalent to "gcc -std=c99 -pedantic"
>> and
>>
>> "pcc64.c", line 3395: warning: initialization type mismatch
>
> OK, thanks. If I add as many options as I can find, I get roughly 2000
> warnings (mostly about unused stuff), for example:
>
> gcc -m64 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -Wshadow
> -Wpointer-arith -Wcast-qual -Wmissing-prototypes -Wno-missing-braces
> -std=c11 -D_GNU_SOURCE pcc64.c -opcc64.exe
>
> but no errors. The pcc64.exe program is produced, and it will run,
> giving a usage message.
>
> What options did you use? (Pretty strict I would bet.)
>
> With C compilers as I normally use them:
>
> gcc (5.1.0 Windows) 0 warnings
> Pelles C 500 warnings (unused labels, unreachable code)
> lccwin 30 warnings
> MSVC 3 warnings
> Tiny C 0 warnings (don't know if it does warnings)
> bcc --- (does not generate warnings)
> gcc (4.4.2 Linux) 1 warning (overflow in numeric constant)
> gcc (6.2.0 Linux) 4 warnings (printf argument mismatch)
> DMC 23 warnings (possible unintended assignments)
>
> It's nice to see how much in agreement C compilers can be about what
> might be amiss in a program!
>
> > It breaks the current version of the compiler
>
> What do you mean by it breaks it?
It warns that an internal static error checker encountered an unexpected
error. It does produce an executable output with 49 warnings, its
default mode is c11.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-28 04:34 -0700 |
| Message-ID | <8d25eac7-251c-4f49-91a2-bbc8cd6c58d2@googlegroups.com> |
| In reply to | #129851 |
On Friday, April 27, 2018 at 3:51:31 AM UTC-7, Bart wrote:
> On 27/04/2018 09:41, Ian Collins wrote:
> > On 04/27/2018 10:48 AM, bartc wrote:
>
> >> (Out of interest, what happens when you compile that pcc64.c file I
> >> linked to earlier [1] on that other machine, assuming it's 64-bit
> >> capable?
> >
> > It breaks the current version of the compiler, an older version rejects
> > it with 3101 warnings/errors. Mostly along the lines of
> >
> > "pcc64.c", line 2785: cannot use an address to initialize a field of a
> > packed struct (#pragma pack)
> >
> > and
> >
> > "pcc64.c", line 16749: improper member use: mutable
>
> (Warning or error? And what's wrong with it? ('mutable' is a member of
> an anonymous union.))
>
> > and
> >
> > "pcc64.c", line 3395: warning: initialization type mismatch
>
> OK, thanks. If I add as many options as I can find, I get roughly 2000
> warnings (mostly about unused stuff), for example:
>
> gcc -m64 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -Wshadow
> -Wpointer-arith -Wcast-qual -Wmissing-prototypes -Wno-missing-braces
> -std=c11 -D_GNU_SOURCE pcc64.c -opcc64.exe
>
> but no errors. The pcc64.exe program is produced, and it will run,
> giving a usage message.
>
> What options did you use? (Pretty strict I would bet.)
>
> With C compilers as I normally use them:
>
> gcc (5.1.0 Windows) 0 warnings
> Pelles C 500 warnings (unused labels, unreachable code)
> lccwin 30 warnings
> MSVC 3 warnings
> Tiny C 0 warnings (don't know if it does warnings)
> bcc --- (does not generate warnings)
> gcc (4.4.2 Linux) 1 warning (overflow in numeric constant)
> gcc (6.2.0 Linux) 4 warnings (printf argument mismatch)
> DMC 23 warnings (possible unintended assignments)
>
> It's nice to see how much in agreement C compilers can be about what
> might be amiss in a program!
>
> > It breaks the current version of the compiler
>
> What do you mean by it breaks it?
>
> --
> bartc
"Now that was close" said Lewis's husband. It's easy to exaggerate by focusing on hardly any special cases unrepresentative from what's something more common like KDE. What matters more from an honest advocates opinion are the regular uses. Both Graham Bell and Lewis had their public farts and their messes. One played it cool and didn't do anything too outrageous that could not be re-done in a way that made it look like he had a clue. Oh goodness, that is just tons of rot.
--
What Every Entrepreneur Must Know
http://www.macadvocacy.pw/2005/Nov/09/236626.html
http://www.5z8.info/racist-raps_r6r3wf_best-russian-sites-for-bootleg-everything
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-26 23:05 -0700 |
| Message-ID | <da6d3658-b82b-4e11-b9ce-1eef7b1e4391@googlegroups.com> |
| In reply to | #129827 |
On Thursday, April 26, 2018 at 3:27:22 PM UTC-7, Ian Collins wrote: > On 04/27/2018 10:16 AM, bartc wrote: > > On 26/04/2018 22:01, Ian Collins wrote: > >> On 04/27/2018 08:44 AM, bartc wrote: > >>> On 26/04/2018 21:18, Ian Collins wrote: > >>>> On 04/27/2018 08:08 AM, bartc wrote: > >>>>> On 26/04/2018 20:48, Ian Collins wrote: > >>>>>> On 04/27/2018 05:04 AM, Philipp Klaus Krause wrote: > >>>>>>> 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. > >>>>>> > >>>>>> Why wouldn't it be recognised? Autoconf just uses the compiler (which > >>>>>> you can identify with "CC=<your compiler>" to compile test code > >>>>>> snippets. > >>>>> > >>>>> If I look at the 18,322-line configure file for CPython in github, then > >>>>> there are hundreds of references to gcc, a lighter sprinkling of icc, > >>>>> but remarkably few references to my compiler. > >>>> > >>>> Did you actually read what I wrote? How do you think I ported numerous > >>>> Linux centric open source projects to Solaris building with Sun's > >>>> compilers? > >>> > >>> Was that with the 'choke me' message for non-GNUC users in the middle of > >>> the configure file? > >>> > >>> Anyway I don't care about other people's gigantic projects; they can use > >>> whatever systems they like. > >>> > >>> I care about the ones /I/ want to build where this stuff is forced down > >>> my throat. > >> > >> You don't care to read what people write ether, do you? Just as a quick > >> experiment to see how hard it is to build CPython on something other > >> than Linux without gcc: > >> > >> export CC=/opt/OracleDeveloperStudio12.6/bin/cc > >> export CPP="/opt/OracleDeveloperStudio12.6/bin/cc -E" > >> ./configure --without-gcc --prefix=/opt/local --enable-optimizations > >> make -J 8 > >> make install > >> /opt/local/bin/python3.8 --version > >> Python 3.8.0a0 > >> ls -l /opt/local/bin/python3.8 > >> -rwxr-xr-x 2 root root 3427860 Apr 27 08:54 > >> /opt/local/bin/python3.8 > >> > >> Wow, that was so hard... > > > > Some questions: > > > > * How did you manage to do ./configure on that other machine? Or does it > > just work because, after all, they are both really Unix? > > > > * Do you try this on Windows? > > I don't have a Windows machine. > > > * What does that other compiler return for the value of __GNUC__? If not > > defined, how does it manage to avoid that trap in the middle of configure? > > I don't care, I configured with "--without-gcc". > > > * What macro does that cc compiler export as its identifier? CPython > > sources explicitly test for MS_WINDOWS, BORLANDC, WATCOMC, DJGPP, GNUC, > > SUNPROC_C, SGI, and SOLARIS among others. > > > > The fact is that on Windows, CPython can't be built with gcc, so they > > have to have a VS solution (which is even more problematic). The build > > process is just too complex. > > That's Windows for you. You could just do what our developers with > Windows desktops do and use Windows Subsystem for Linux (WSL). > > > Another question: with whatever compiler was used on that other machine, > > do you think it worked perfectly the first time it was used to compile > > CPython, without the need to touch 'configure' at all or any part of the > > CPython sources? > > Why should it? That's not how the build system is designed. > > > Or is it possible that what you are seeing represents a considerable > > amount of work to make it happen? > > Someone else's work, not mine. > > CPython is something called a "project" which has people called > "maintainers". I suggest you familiarise yourself with those terms. > > -- > Ian. Honestly, those of you who troll are not able to restrain KDE anymore. It was Thiago 'The Shill' Adams who stated that he and his college buddies used to steal candy from toddlers all the time and it was just fun. Why do you keep repeating yourself? I am a complete devotee of KDE, because that's where all the compelling modernization is happening. Open source is only less expensive if your time has no value. The "advocates" value conformity more than they do productivity. Thiago 'The Shill' Adams asked to be rated according to direct statistical evidence, which I obliged him with. -- Do not click this link! http://www.5z8.info/open.exe_f2s2ea_nazi http://www.5z8.info/boobs_j0v3qo_dont-just-drizzle Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-04-27 00:52 +0200 |
| Message-ID | <pbtl7m$c8a$1@dont-email.me> |
| In reply to | #129826 |
Le 27/04/2018 à 00:16, bartc a écrit : > * Do you try this on Windows? Dear Bart: Using Microsoft system is problematic, as you see, you can't do that on windows. And you can't do many other things. Yes, you can use the machine and program it as you want if you put the necessary effort, but it is a pain to use that system. I coped for years with Microsoft, but they stopped supporting C, and even C++ is suspect now... Only C# (that replaced basic as the language of the company of B. Gates) is now "in vogue", and I did find building tools in that system increasingly difficult, as I reported in this discussion group some years ago. When I used windows however I was always aware that I would have to port anything that comes from the Unix world. Most of the time it was relatively easy. "bzero" was to be replaced by memset or similar stuff. More difficult to port were pthreads and network code, where I could earn some consulting fees. But never I would have thought that taking a piece of unix software and trying to compile it blindly would work, sorry. I just knew it would not work. True, I never proved it, and now you have proved it Bart. IT IS OFFICIAL: Bart has PROVED that trying to compile Unix software will not work on windows "as is"... This tremendous fact, known to all but Bart has been officially closed: BART has proved to himself that compiling unix code doesn't work on windows. I hope you are proud of your achievement and go on ranting as usual. Yours sincerely jacob
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-26 16:23 -0700 |
| Message-ID | <05cdde0f-bd9a-480f-9a26-63872dc767c7@googlegroups.com> |
| In reply to | #129831 |
On Thursday, April 26, 2018 at 5:52:45 PM UTC-5, jacobnavia wrote: > Using Microsoft system is problematic, as you see, you can't do that on > windows. I don't think Windows is unique. Really, the problem is that a lot of programs aren't really written in C--they're written in Unix's combination of C, scripts, etc. > And you can't do many other things. Yes, you can use the machine and > program it as you want if you put the necessary effort, but it is a pain > to use that system. Many people do many useful things with Windows, but many Unix programmers regard that notion as mythical. > I coped for years with Microsoft, but they stopped supporting C, and > even C++ is suspect now... Only C# (that replaced basic as the language > of the company of B. Gates) is now "in vogue", and I did find building > tools in that system increasingly difficult, as I reported in this > discussion group some years ago. The languages processed by MSVC and gcc have diverged from each other, largely because MSVC has sought to remain compatible with older versions of the language extending back even before C89, without regard for whether the Standard required it to do so. It's been awhile since I've done native C programming on the PC, but I thought MSVC seemed like a perfectly fine development environment. > But never I would have thought that taking a piece of unix software and > trying to compile it blindly would work, sorry. I just knew it would not > work. True, I never proved it, and now you have proved it Bart. If a command-line application doesn't do anything not supported by the Standard library, why shouldn't it be written to "just work" on pretty much any machine that supports 8/16/32/64-bit numeric types, rather than only on Unix machines?
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web