Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #103611 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2017-02-10 17:16 +0000 |
| Last post | 2017-02-11 03:17 -0800 |
| Articles | 20 on this page of 105 — 19 participants |
Back to article view | Back to comp.lang.c
Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 17:16 +0000
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-10 09:33 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 18:41 +0000
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-10 12:09 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 20:29 +0000
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-10 13:26 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 22:56 +0000
Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-10 20:19 -0800
Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-11 09:53 -0500
Re: Is 'extern' necessary? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-13 05:19 -0800
Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-10 12:09 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 20:50 +0000
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-10 13:09 -0800
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-10 13:33 -0800
Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 23:23 +0000
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 23:35 +0000
Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-11 00:34 +0000
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 12:41 +0100
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-13 13:14 +0000
Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-13 14:05 +0000
Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-13 07:49 -0800
Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-10 19:33 -0800
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-11 09:41 -0800
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-11 10:19 -0800
Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-11 13:39 -0500
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-12 10:10 -0800
Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-10 14:59 -0800
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 12:33 +0100
Re: Is 'extern' necessary? Siri Cruise <chine.bleu@yahoo.com> - 2017-02-10 09:35 -0800
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-10 12:12 -0800
Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-10 10:38 -0800
Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 21:10 +0000
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-10 13:25 -0800
Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-10 14:53 -0800
Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-10 15:06 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-10 23:24 +0000
Re: Is 'extern' necessary? Ian Collins <ian-news@hotmail.com> - 2017-02-11 12:34 +1300
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 13:14 +0100
Re: Is 'extern' necessary? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-13 13:44 +0100
Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-13 14:13 +0000
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 15:16 +0100
Re: Is 'extern' necessary? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-13 17:24 +0100
Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-13 14:24 -0500
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 23:29 +0100
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-13 11:06 -0800
Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-13 11:15 -0800
Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-13 11:48 -0500
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-13 09:03 -0800
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-13 23:37 +0100
Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-10 15:40 -0800
Re: Is 'extern' necessary? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-13 05:09 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-13 13:46 +0000
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-13 09:52 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-13 19:19 +0000
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-13 11:34 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-13 20:13 +0000
Re: Is 'extern' necessary? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-13 13:11 -0800
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 00:33 +0100
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-14 01:02 +0000
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 09:28 +0100
Re: Is 'extern' necessary? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-14 03:31 -0600
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-14 11:42 +0000
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 13:29 +0100
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-14 05:16 -0800
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 14:51 +0100
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-14 07:24 -0800
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 21:35 +0100
Re: Is 'extern' necessary? James Kuyper <jameskuyper@verizon.net> - 2017-02-14 15:53 -0500
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-15 09:31 +0100
Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-15 11:36 -0500
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-15 09:12 -0800
Re: Is 'extern' necessary? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-15 12:58 -0500
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-15 10:01 -0800
Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-15 10:55 -0800
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-15 11:42 -0800
Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-15 12:28 -0800
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-15 13:58 -0800
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-14 08:54 -0800
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-14 08:51 -0800
Re: Is 'extern' necessary? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-14 17:32 +0000
Re: Is 'extern' necessary? Gareth Owen <gwowen@gmail.com> - 2017-02-14 17:45 +0000
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-14 21:38 +0100
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-14 23:26 +0000
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-14 16:33 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-15 00:47 +0000
Re: Is 'extern' necessary? Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-14 18:17 +0100
Re: Is 'extern' necessary? Keith Thompson <kst-u@mib.org> - 2017-02-14 09:47 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-14 18:36 +0000
Re: Is 'extern' necessary? jameskuyper@verizon.net - 2017-02-14 11:20 -0800
Re: Is 'extern' necessary? supercat@casperkitty.com - 2017-02-14 11:42 -0800
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-14 20:22 +0000
Re: Is 'extern' necessary? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-14 17:58 -0600
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-15 01:29 +0000
Re: Is 'extern' necessary? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-16 05:02 -0600
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-16 11:38 +0000
Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-16 14:37 +0000
Re: Is 'extern' necessary? BartC <bc@freeuk.com> - 2017-02-16 15:43 +0000
Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-16 16:08 +0000
Re: Is 'extern' necessary? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-16 18:42 +0100
Re: Is 'extern' necessary? David Brown <david.brown@hesbynett.no> - 2017-02-15 09:47 +0100
Re: Is 'extern' necessary? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-16 05:05 -0600
Re: Is 'extern' necessary? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-15 16:53 -0800
Re: Is 'extern' necessary? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 23:55 +0000
Re: Is 'extern' necessary? Les Cargill <lcargill99@comcast.com> - 2017-02-10 19:24 -0600
Re: Is 'extern' necessary? void <nathan.gothier@gmail.com> - 2017-02-11 03:17 -0800
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-02-14 17:45 +0000 |
| Message-ID | <87r3303bu9.fsf@gmail.com> |
| In reply to | #103898 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 14/02/17 16:51, Keith Thompson wrote: >> Of course it is. MinGW is an implementation that include gcc as its >> compiler. The library component of MinGW is, as far as I know, intended >> to work with gcc, and only with gcc. Has anyone claimed otherwise? > > No, of course they haven't. YHBT. Repeatedly, and with a desire to endlessly be right blocking the self awareness to notice when its happening. ObXKCD "Someone on the Internet is wrong"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-14 21:38 +0100 |
| Message-ID | <o7vpoh$kgm$2@dont-email.me> |
| In reply to | #103886 |
On 14/02/17 17:51, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 14/02/2017 08:28, David Brown wrote: > [...] >>> Standard library code is part of the implementation. Even if it is >>> developed separately from the compiler, it is still in close cooperation >>> with the compiler. >> >> "The" compiler? I thought such libraries were completely independent >> from any one compiler and were all interchangable? > > What gave you that idea? > I believe I gave him that idea by saying that the library is a separate project from the compiler, and that some C libraries can be used with multiple compilers - or at least different versions and targets of the same basic compiler. Extending this to think that this means that the library in question is completely independent and interchangeable, is Bart's extrapolation of that. >> Or you finally admitting that perhaps the MingW library /is/ really >> designed to work with gcc? > > "finally admitting"? > > Of course it is. MinGW is an implementation that include gcc as its > compiler. The library component of MinGW is, as far as I know, intended > to work with gcc, and only with gcc. Has anyone claimed otherwise? > > [...] >
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-14 23:26 +0000 |
| Message-ID | <o803kj$ra5$1@dont-email.me> |
| In reply to | #103886 |
On 14/02/2017 16:51, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 14/02/2017 08:28, David Brown wrote: > [...] >>> Standard library code is part of the implementation. Even if it is >>> developed separately from the compiler, it is still in close cooperation >>> with the compiler. >> >> "The" compiler? I thought such libraries were completely independent >> from any one compiler and were all interchangable? > > What gave you that idea? > >> Or you finally admitting that perhaps the MingW library /is/ really >> designed to work with gcc? > > "finally admitting"? > > Of course it is. MinGW is an implementation that include gcc as its > compiler. The library component of MinGW is, as far as I know, intended > to work with gcc, and only with gcc. Has anyone claimed otherwise? I think so. I remember long threads with people telling me why it makes perfect sense to have compiler installations that are only a bare compiler without all the extra bits needed to compile Hello World. But if MingW is designed to work only with gcc-for-Windows, and gcc-for-Windows works best with MingW, and most people using gcc-for-Windows end up with Mingw, then why split gcc-for-Windows/Mingw into two parts? I think actually there were three parts. I don't know what was in the third part; linkers and such? Whatever it was, the components are so obviously designed to work together, then it would make sense for a gcc-for-Windows installation to have everything people need to build C applications. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-14 16:33 -0800 |
| Message-ID | <ln8tp8s366.fsf@kst-u.example.com> |
| In reply to | #103911 |
BartC <bc@freeuk.com> writes:
> On 14/02/2017 16:51, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 14/02/2017 08:28, David Brown wrote:
>> [...]
>>>> Standard library code is part of the implementation. Even if it is
>>>> developed separately from the compiler, it is still in close cooperation
>>>> with the compiler.
>>>
>>> "The" compiler? I thought such libraries were completely independent
>>> from any one compiler and were all interchangable?
>>
>> What gave you that idea?
>>
>>> Or you finally admitting that perhaps the MingW library /is/ really
>>> designed to work with gcc?
>>
>> "finally admitting"?
>>
>> Of course it is. MinGW is an implementation that include gcc as its
>> compiler. The library component of MinGW is, as far as I know, intended
>> to work with gcc, and only with gcc. Has anyone claimed otherwise?
>
> I think so. I remember long threads with people telling me why it
> makes perfect sense to have compiler installations that are only a
> bare compiler without all the extra bits needed to compile Hello
> World.
>
> But if MingW is designed to work only with gcc-for-Windows, and
> gcc-for-Windows works best with MingW, and most people using
> gcc-for-Windows end up with Mingw, then why split
> gcc-for-Windows/Mingw into two parts?
>
> I think actually there were three parts. I don't know what was in the
> third part; linkers and such? Whatever it was, the components are so
> obviously designed to work together, then it would make sense for a
> gcc-for-Windows installation to have everything people need to build C
> applications.
Bart, I've decided to cut back substantially on my followups to
your posts. There are several errors in what you've just written.
If you'd like me to discuss them, contact me by e-mail (I don't
actively monitor this account so it might take a while before I
see anything you send me).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-15 00:47 +0000 |
| Message-ID | <o808bc$8q9$1@dont-email.me> |
| In reply to | #103915 |
On 15/02/2017 00:33, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> But if MingW is designed to work only with gcc-for-Windows, and
>> gcc-for-Windows works best with MingW, and most people using
>> gcc-for-Windows end up with Mingw, then why split
>> gcc-for-Windows/Mingw into two parts?
>>
>> I think actually there were three parts. I don't know what was in the
>> third part; linkers and such? Whatever it was, the components are so
>> obviously designed to work together, then it would make sense for a
>> gcc-for-Windows installation to have everything people need to build C
>> applications.
>
> Bart, I've decided to cut back substantially on my followups to
> your posts. There are several errors in what you've just written.
> If you'd like me to discuss them, contact me by e-mail (I don't
> actively monitor this account so it might take a while before I
> see anything you send me).
No, forget it.
Looking back up the thread, the discussion seemed to follow on from this
throwaway remark of mine on encountering this:
extern
__attribute__((__format__ (gnu_printf, 3, 0))) __MINGW_ATTRIB_NONNULL(3)
int __cdecl __mingw_vsnprintf(char * __restrict__ _DstBuf,size_t
_MaxCount,const char * __restrict__ _Format,
va_list _ArgList);
I'll refrain from commenting again and just leave it there for others to
enjoy.
--
bartc
(That refraining didn't really work did it...?)
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2017-02-14 18:17 +0100 |
| Message-ID | <87vascn13j.fsf@news.bourguet.org> |
| In reply to | #103867 |
BartC <bc@freeuk.com> writes: > Or you finally admitting that perhaps the MingW library /is/ really > designed to work with gcc? They provide a modified gcc to work with Microsoft's C runtime. Most of the C library used by MinGW for sure was *not* designed to work with gcc. Yours, -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-14 09:47 -0800 |
| Message-ID | <lnd1ekslyx.fsf@kst-u.example.com> |
| In reply to | #103893 |
Jean-Marc Bourguet <jm@bourguet.org> writes:
> BartC <bc@freeuk.com> writes:
>> Or you finally admitting that perhaps the MingW library /is/ really
>> designed to work with gcc?
>
> They provide a modified gcc to work with Microsoft's C runtime. Most of
> the C library used by MinGW for sure was *not* designed to work with gcc.
The stdio.h header file BartC quoted is clearly part of MinGW, and
apparently was designed specifically to work with MinGW's version of
gcc.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-14 18:36 +0000 |
| Message-ID | <o7vijo$pun$1@dont-email.me> |
| In reply to | #103901 |
On 14/02/2017 17:47, Keith Thompson wrote: > Jean-Marc Bourguet <jm@bourguet.org> writes: >> BartC <bc@freeuk.com> writes: >>> Or you finally admitting that perhaps the MingW library /is/ really >>> designed to work with gcc? >> >> They provide a modified gcc to work with Microsoft's C runtime. Most of >> the C library used by MinGW for sure was *not* designed to work with gcc. > > The stdio.h header file BartC quoted is clearly part of MinGW, and > apparently was designed specifically to work with MinGW's version of > gcc. I'm starting to suspect that nobody here knows exactly what's what. People say that a C compiler is independent of any set of headers, but then if you try and run one compiler with another's standard headers, you run into problems. Can a C compiler be said to work with C90, C99 or C11 code, and yet not come with any of its own header files? Would you pay money for a compiler that was just a compiler with no standard headers? I think that a particular implementation is a package that consists of everything /extra/ that is needed to compile a C program and do whatever is necessary to create and run an executable. That doesn't mean relying on /other/ compilers and or their standard headers and possibly libraries, unless a compiler has been designed to do just that (eg. clang, although my beef with that product is that they don't tell you this vital detail; they assume that you know). -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-14 11:20 -0800 |
| Message-ID | <6fc15d14-8a21-4f96-96fe-a430c486f615@googlegroups.com> |
| In reply to | #103903 |
On Tuesday, February 14, 2017 at 1:36:30 PM UTC-5, Bart wrote: > On 14/02/2017 17:47, Keith Thompson wrote: > > Jean-Marc Bourguet <jm@bourguet.org> writes: > >> BartC <bc@freeuk.com> writes: > >>> Or you finally admitting that perhaps the MingW library /is/ really > >>> designed to work with gcc? > >> > >> They provide a modified gcc to work with Microsoft's C runtime. Most of > >> the C library used by MinGW for sure was *not* designed to work with gcc. > > > > The stdio.h header file BartC quoted is clearly part of MinGW, and > > apparently was designed specifically to work with MinGW's version of > > gcc. > > I'm starting to suspect that nobody here knows exactly what's what. > > People say that a C compiler is independent of any set of headers, but I don't remember anyone making that statement in general. Some particular C compilers come with no implementation of the C standard library of their own, and rely upon using one provided by some other vendor. Note: the headers are only part of the library, and a relatively minor part; the main part is the library file itself. > then if you try and run one compiler with another's standard headers, > you run into problems. > > Can a C compiler be said to work with C90, C99 or C11 code, and yet not > come with any of its own header files? A pure compiler can never qualify as a complete implementation of the C standard by itself. It can only qualify in combination with an implementation of the C standard library and a linker. Whether compiler1 + standard_library2 + linker3 constitutes a conforming implementation of C depends up what those three components are; many combinations don't work, and I can't remember anyone claiming that all possible combinations are guaranteed to work. > Would you pay money for a compiler that was just a compiler with no > standard headers? No, but then, I wouldn't pay money for a compiler, period. Ones that are good enough for my needs are available for free. I could easily afford to pay even a fairly high price for a compiler, if I knew of any good reason to do so - but I know of no such reason.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-14 11:42 -0800 |
| Message-ID | <ca07b3fc-303f-4a88-9cf8-63b383efd8a1@googlegroups.com> |
| In reply to | #103903 |
On Tuesday, February 14, 2017 at 12:36:30 PM UTC-6, Bart wrote: > People say that a C compiler is independent of any set of headers, but > then if you try and run one compiler with another's standard headers, > you run into problems. A conforming C implementation will generally need to contain a compiler and a set of libraries which work with each other (in theory, the compiler could include within itself all of the logic to produce inline code for all "standard library" functions, and consequently not need any other library, but in practice that isn't done). Even if the compiler and library are supplied by different entities, I find curious the notion that the headers should be supplied by the library vendor rather than the compiler. The Standard says that if user code declares a function pointer whose signature matches that of a Standard Library function, assigns to that pointer the address of that function, and makes a call through that pointer, behavior will in most cases be defined as equivalent to calling the library function "normally". I'm not sure the value of that guarantee exceeds the cost, but the Standard requires it for most library functions. Given that a library must contain functions which can be invoked through the prototypes defined by the Standard, I'm not sure what a library could include in its headers, beyond the definitions given in the Standard, without relying upon compiler-specific extensions. I would think there would be a lot more room for a compiler to use its own headers to supplant standard library functions with intrinsics.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-14 20:22 +0000 |
| Message-ID | <o7voq8$hnb$1@dont-email.me> |
| In reply to | #103905 |
On 14/02/2017 19:42, supercat@casperkitty.com wrote: > On Tuesday, February 14, 2017 at 12:36:30 PM UTC-6, Bart wrote: >> People say that a C compiler is independent of any set of headers, but >> then if you try and run one compiler with another's standard headers, >> you run into problems. > > A conforming C implementation will generally need to contain a compiler and > a set of libraries which work with each other (in theory, the compiler could > include within itself all of the logic to produce inline code for all > "standard library" functions, and consequently not need any other library, > but in practice that isn't done). The implementation I'm working on won't have its own C library. It'll use what's already available (in msvcrt.dll or libc.so.6). Maybe there are various new C functions that are not included in those two libraries and that I'd have to provide (I'm only familiar with a tiny part of the library) in which case they will probably be provided inside my program (or more likely, I won't bother; this is only an experiment done for fun). I haven't worked out what to do about standard headers; probably they will be built-in (no physical external files). And specific to the compiler. (But for things such as windows.h, and for any other libraries not part of the language, they will need to be provided by a host, as it's too much work otherwise. Preferably not gcc/mingw, as that involves 150 files/340K lines, and is probably full of gcc-specific dependencies so wouldn't work.) > Given that a library must contain functions which can be invoked through the > prototypes defined by the Standard, I'm not sure what a library could > include in its headers, beyond the definitions given in the Standard, without > relying upon compiler-specific extensions. I would think there would be a > lot more room for a compiler to use its own headers to supplant standard > library functions with intrinsics. Well, clang (on Windows anyway) used to work with a local gcc's headers, now it works with MSVC's header, as well as using their linkers. So it can be done, although clang is not small nor that much faster at compiling that gcc. (You do wonder what on earth is inside its 50MB executable since most things are borrowed from elsewhere!) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-14 17:58 -0600 |
| Message-ID | <an57ac9td0qb00al2a38kr9na8jj8ar695@4ax.com> |
| In reply to | #103903 |
On Tue, 14 Feb 2017 18:36:20 +0000, BartC <bc@freeuk.com> wrote: >People say that a C compiler is independent of any set of headers, Independent of any particular set, yes, but headers and compiler must be designed to work together. Which perfectly allows headers that work with multiple compilers, and compilers that work with multiple sets of headers, both of those simultaneously, or compilers and headers only have single (existing) partners they work with. What's not required is that all compilers work with all headers. In fact the standard *requires* that the headers and compilers understand each others *unspecified* behavior well enough to implement things like the offsetof macro. > but >then if you try and run one compiler with another's standard headers, >you run into problems. That's a silly extrapolation. >Can a C compiler be said to work with C90, C99 or C11 code, and yet not >come with any of its own header files? Such a thing would not actually be a full implementation of C (whichever standard), and so doesn't have do much of anything from the standard's perspective.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-15 01:29 +0000 |
| Message-ID | <o80apg$evk$1@dont-email.me> |
| In reply to | #103914 |
On 14/02/2017 23:58, Robert Wessel wrote: > On Tue, 14 Feb 2017 18:36:20 +0000, BartC <bc@freeuk.com> wrote: > >> People say that a C compiler is independent of any set of headers, > > > Independent of any particular set, yes, but headers and compiler must > be designed to work together. Which perfectly allows headers that > work with multiple compilers, and compilers that work with multiple > sets of headers, both of those simultaneously, or compilers and > headers only have single (existing) partners they work with. What's > not required is that all compilers work with all headers. > > In fact the standard *requires* that the headers and compilers > understand each others *unspecified* behavior well enough to implement > things like the offsetof macro. > > >> but >> then if you try and run one compiler with another's standard headers, >> you run into problems. > > > That's a silly extrapolation. Some years ago I'd complained here about problems I'd been having about certain compilers** that didn't come with standard headers etc. And everyone said it was a perfectly normal thing to do. I disagreed. I think a compiler for a certain platform and target should come with everything included. But apparently the rules don't apply to gcc as it makes up its own. (** Some distributions for gcc on Windows came in multiple downloads and you had to download the right set to make up the complete suite. Others would include the full bundle. While Clang for Windows expected to make use of an already installed gcc or MSVC, but neglected to tell you that. All other compilers for Windows I've used come with everything needed.) >> Can a C compiler be said to work with C90, C99 or C11 code, and yet not >> come with any of its own header files? > > > Such a thing would not actually be a full implementation of C > (whichever standard), and so doesn't have do much of anything from the > standard's perspective. OK, so Clang for Windows isn't a full implementation then. And you're perfectly right as it currently doesn't work! (I don't have an MSVC installation it can hook on to and it no longer works with gcc.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-16 05:02 -0600 |
| Message-ID | <uc1bactk5hbpqdqsa832d6u00m61lks5c2@4ax.com> |
| In reply to | #103918 |
On Wed, 15 Feb 2017 01:29:00 +0000, BartC <bc@freeuk.com> wrote: >On 14/02/2017 23:58, Robert Wessel wrote: >> On Tue, 14 Feb 2017 18:36:20 +0000, BartC <bc@freeuk.com> wrote: >> >>> People say that a C compiler is independent of any set of headers, >> >> >> Independent of any particular set, yes, but headers and compiler must >> be designed to work together. Which perfectly allows headers that >> work with multiple compilers, and compilers that work with multiple >> sets of headers, both of those simultaneously, or compilers and >> headers only have single (existing) partners they work with. What's >> not required is that all compilers work with all headers. >> >> In fact the standard *requires* that the headers and compilers >> understand each others *unspecified* behavior well enough to implement >> things like the offsetof macro. >> >> >>> but >>> then if you try and run one compiler with another's standard headers, >>> you run into problems. >> >> >> That's a silly extrapolation. > >Some years ago I'd complained here about problems I'd been having about >certain compilers** that didn't come with standard headers etc. And >everyone said it was a perfectly normal thing to do. > >I disagreed. I think a compiler for a certain platform and target should >come with everything included. But apparently the rules don't apply to >gcc as it makes up its own. > >(** Some distributions for gcc on Windows came in multiple downloads and >you had to download the right set to make up the complete suite. Others >would include the full bundle. While Clang for Windows expected to make >use of an already installed gcc or MSVC, but neglected to tell you that. > >All other compilers for Windows I've used come with everything needed.) > >>> Can a C compiler be said to work with C90, C99 or C11 code, and yet not >>> come with any of its own header files? >> >> >> Such a thing would not actually be a full implementation of C >> (whichever standard), and so doesn't have do much of anything from the >> standard's perspective. > >OK, so Clang for Windows isn't a full implementation then. And you're >perfectly right as it currently doesn't work! (I don't have an MSVC >installation it can hook on to and it no longer works with gcc.) That's rather a straw man. No one would ever disagree that it would be nice if the installation of a complete C implementation were trivial. But if it isn't, that's a QoI issue, and has nothing to to with its validity as a C implementation. In any event what's "easy" is also dependent on the environment. Gcc has *nix as one of its major use cases - and there, in most cases, the installation is so trivial that's there's no work at all, despite glibc and gcc coming from rather different places.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-16 11:38 +0000 |
| Message-ID | <o842s8$fmk$1@dont-email.me> |
| In reply to | #103987 |
On 16/02/2017 11:02, Robert Wessel wrote: > On Wed, 15 Feb 2017 01:29:00 +0000, BartC <bc@freeuk.com> wrote: >> I disagreed. I think a compiler for a certain platform and target should >> come with everything included. But apparently the rules don't apply to >> gcc as it makes up its own. > That's rather a straw man. No one would ever disagree that it would > be nice if the installation of a complete C implementation were > trivial. But if it isn't, that's a QoI issue, and has nothing to to > with its validity as a C implementation. In any event what's "easy" > is also dependent on the environment. Gcc has *nix as one of its > major use cases - and there, in most cases, the installation is so > trivial that's there's no work at all, despite glibc and gcc coming > from rather different places. Is it so trivial? I had to upgrade a gcc version on Linux and the process was anything but (according to instructions I found on the net). It took forever, as apparently a million other things had to be upgraded too. On one machine, the upgrade seemed to be so drawn out that I pressed control-C, which left Ubuntu in an unstable state, and I had to entirely re-install that virtual OS. And this is installing a ready-built version. I don't know what it would be like building a 100,000-file application from source; I hardly imagine it would be 'no work at all'. (I work on Windows and strive to make [console] apps work on Linux too. I think they end up better than Linux apps that say they work on Windows, laden as they still are with dozens of dependencies on Linux utilities. Only yesterday I wasn't able to compile 'subc' (a C compiler) because it relied on 'configure' and 'make'. 'configure' doesn't work on Windows. Typing 'make' gave me the message: 'Use ./configure instead'. The README told me I could build without make with 'cc *.c' but that didn't work because the headers contained metadata (presumably to be configured into proper C) not C source. Unix/Linux seems to taint all such applications in the same manner; it seems to be utterly beyond their control to create a C application which is just plain old C requiring a C compiler AND NOTHING ELSE. All the more reason why I try and make my own apps as hassle-free as possible. You won't need to upgrade your entire OS first!) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-16 14:37 +0000 |
| Message-ID | <87vasanqw8.fsf@bsb.me.uk> |
| In reply to | #103993 |
BartC <bc@freeuk.com> writes: > On 16/02/2017 11:02, Robert Wessel wrote: >> On Wed, 15 Feb 2017 01:29:00 +0000, BartC <bc@freeuk.com> wrote: > >>> I disagreed. I think a compiler for a certain platform and target should >>> come with everything included. But apparently the rules don't apply to >>> gcc as it makes up its own. > >> That's rather a straw man. No one would ever disagree that it would >> be nice if the installation of a complete C implementation were >> trivial. But if it isn't, that's a QoI issue, and has nothing to to >> with its validity as a C implementation. In any event what's "easy" >> is also dependent on the environment. Gcc has *nix as one of its >> major use cases - and there, in most cases, the installation is so >> trivial that's there's no work at all, despite glibc and gcc coming >> from rather different places. > > Is it so trivial? Yes, "in most cases". In fact, I don't even recall having installed it though I must have done once. > I had to upgrade a gcc version on Linux and the > process was anything but (according to instructions I found on the > net). It took forever, as apparently a million other things had to be > upgraded too. That's not "installing gcc". <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-16 15:43 +0000 |
| Message-ID | <o84h8d$20g$1@dont-email.me> |
| In reply to | #104007 |
On 16/02/2017 14:37, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Is it so trivial? > > Yes, "in most cases". In fact, I don't even recall having installed it > though I must have done once. So you don't know what it entails. If you look online you get advice like this: sudo apt-get update sudo apt-get install gcc-4.6 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 20 sudo update-alternatives --config gcc >> I had to upgrade a gcc version on Linux and the >> process was anything but (according to instructions I found on the >> net). It took forever, as apparently a million other things had to be >> upgraded too. > > That's not "installing gcc". You'd think upgrading would be simpler than installing. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-16 16:08 +0000 |
| Message-ID | <87k28qp18a.fsf@bsb.me.uk> |
| In reply to | #104012 |
BartC <bc@freeuk.com> writes: > On 16/02/2017 14:37, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> Is it so trivial? >> >> Yes, "in most cases". In fact, I don't even recall having installed it >> though I must have done once. > > So you don't know what it entails. If you look online you get advice > like this: > > sudo apt-get update > sudo apt-get install gcc-4.6 > sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 20 > sudo update-alternatives --config gcc Don't trust everything you read online. I would never try something like that. I've just tried the obvious sudo apt-get install gcc on another machine and seemed to work, though I would probably have done sudo apt-get install build-essential on my main machine originally. >>> I had to upgrade a gcc version on Linux and the >>> process was anything but (according to instructions I found on the >>> net). It took forever, as apparently a million other things had to be >>> upgraded too. >> >> That's not "installing gcc". > > You'd think upgrading would be simpler than installing. It is. It involves (for me) no action at all in that gcc (and friends) are upgraded automatically with the system. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-02-16 18:42 +0100 |
| Message-ID | <20170216184209.172fa53c1d0066d705bae081@gmail.com> |
| In reply to | #103993 |
On Thu, 16 Feb 2017 11:38:28 +0000 BartC <bc@freeuk.com> wrote: > Only yesterday I wasn't able to compile 'subc' (a C compiler) because it > relied on 'configure' and 'make'. 'configure' doesn't work on Windows. > Typing 'make' gave me the message: 'Use ./configure instead'. The README > told me I could build without make with 'cc *.c' but that didn't work > because the headers contained metadata (presumably to be configured into > proper C) not C source. In theory Autotools are magics, in practice they just generate so many craps in a such manner that you should be lucky when you can output a functional binary. > Unix/Linux seems to taint all such applications in the same manner; it > seems to be utterly beyond their control to create a C application which > is just plain old C requiring a C compiler AND NOTHING ELSE. > > All the more reason why I try and make my own apps as hassle-free as > possible. You won't need to upgrade your entire OS first!) > > -- > bartc Good programmers write good make files and install/uninstall scripts. Nevertheless some programmers think it's out of their scope to write such useful files and rely on Autotools of the devil...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-15 09:47 +0100 |
| Message-ID | <o814fk$9tb$1@dont-email.me> |
| In reply to | #103914 |
On 15/02/17 00:58, Robert Wessel wrote: > On Tue, 14 Feb 2017 18:36:20 +0000, BartC <bc@freeuk.com> wrote: > >> People say that a C compiler is independent of any set of headers, > > > Independent of any particular set, yes, but headers and compiler must > be designed to work together. Which perfectly allows headers that > work with multiple compilers, and compilers that work with multiple > sets of headers, both of those simultaneously, or compilers and > headers only have single (existing) partners they work with. What's > not required is that all compilers work with all headers. > > In fact the standard *requires* that the headers and compilers > understand each others *unspecified* behavior well enough to implement > things like the offsetof macro. > I think it is more correct to say requires that the headers and compilers understand each others behaviour beyond that standards-defined behaviour well enough to implement things like the offset macro. There is certainly no need for the behaviour to be unspecified in general - merely that it is undefined by the C standards. In particular, the offsetof macro definition most commonly used with gcc is: #define offsetof(type, member) __builtin_offsetof (type, member) Since this is documented, it is implementation-specified behaviour rather than unspecified behaviour. A compiler may also say in its documentation that the common definition: #define offsetof(st, m) ((size_t)&(((st *)0)->m)) is allowed. Of course, a compiler can also treat such a definition as legal only if the macro is called "offsetof" and it is in a header <stddef.h>, and launch nasal daemons if you try to use the same sort of construct anywhere else. (That's a hint to Bart - if you find something interesting in one of the compiler's header files, don't assume you can copy it in your own code.)
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web