Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #147447 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2019-11-01 08:42 -0400 |
| Last post | 2019-11-01 23:19 +0000 |
| Articles | 20 on this page of 88 — 19 participants |
Back to article view | Back to comp.lang.c
memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 08:42 -0400
Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 08:49 -0400
Re: memcpy not memcpying? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-01 09:24 -0400
Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 09:46 -0400
Re: memcpy not memcpying? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-01 09:49 -0400
Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-01 10:19 -0700
Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-01 21:14 +0100
Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 17:16 -0400
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-01 22:42 +0000
Re: memcpy not memcpying? Richard Damon <Richard@Damon-Family.org> - 2019-11-01 21:10 -0400
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 11:36 +0000
Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-02 02:15 -0700
Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-02 13:04 +0100
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 13:43 +0000
Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-02 17:24 +0100
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 17:00 +0000
Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-02 13:06 -0700
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 21:05 +0000
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 22:40 +0000
Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-02 15:59 -0700
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-02 23:47 +0000
Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-02 18:22 -0700
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 13:27 +0000
Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-03 17:46 +0100
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 17:20 +0000
Re: memcpy not memcpying? Manfred <noname@add.invalid> - 2019-11-03 19:44 +0100
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 19:36 +0000
Re: memcpy not memcpying? Manfred <noname@add.invalid> - 2019-11-03 22:57 +0100
Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-03 22:39 +0000
Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-03 23:06 +0100
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 23:28 +0000
Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-04 11:00 +0100
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-04 11:14 +0000
Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-04 11:22 +0000
Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-04 13:10 +0100
Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-04 10:03 -0800
Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-04 19:36 +0000
Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-05 10:04 -0800
Re: memcpy not memcpying? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-04 20:58 -0800
Re: memcpy not memcpying? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-04 22:01 -0800
Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-04 12:56 +0100
Re: memcpy not memcpying? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-04 09:50 -0500
Re: memcpy not memcpying? scott@slp53.sl.home (Scott Lurndal) - 2019-11-04 20:26 +0000
Re: memcpy not memcpying? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-04 04:34 -0800
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-04 13:05 +0000
Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-04 14:09 +0000
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-04 15:11 +0000
Re: memcpy not memcpying? Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-04 15:15 +0000
Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-04 15:43 +0000
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 20:20 +0000
Re: memcpy not memcpying? Ian Collins <ian-news@hotmail.com> - 2019-11-03 14:37 +1300
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 11:01 +0000
Re: memcpy not memcpying? Öö Tiib <ootiib@hot.ee> - 2019-11-03 04:03 -0800
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 12:52 +0000
Re: memcpy not memcpying? Öö Tiib <ootiib@hot.ee> - 2019-11-03 23:34 -0800
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-04 09:36 +0000
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-04 16:20 +0000
Re: memcpy not memcpying? Ian Collins <ian-news@hotmail.com> - 2019-11-04 07:46 +1300
Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-03 12:26 -0800
Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-03 17:31 +0100
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-03 17:05 +0000
Re: memcpy not memcpying? already5chosen@yahoo.com - 2019-11-03 09:14 -0800
Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-03 12:32 -0800
Re: memcpy not memcpying? already5chosen@yahoo.com - 2019-11-03 14:59 -0800
Re: memcpy not memcpying? already5chosen@yahoo.com - 2019-11-03 15:19 -0800
Re: memcpy not memcpying? already5chosen@yahoo.com - 2019-11-03 17:00 -0800
Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-02 11:16 -0400
Re: memcpy not memcpying? David Brown <david.brown@hesbynett.no> - 2019-11-02 17:26 +0100
Re: memcpy not memcpying? Barry Schwarz <schwarzb@delq.com> - 2019-11-01 06:39 -0700
Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 09:56 -0400
Re: memcpy not memcpying? Barry Schwarz <schwarzb@delq.com> - 2019-11-01 12:39 -0700
Re: memcpy not memcpying? guinness.tony@gmail.com - 2019-11-01 06:49 -0700
Re: memcpy not memcpying? jak <nospam@please.ty> - 2019-11-01 20:40 +0100
Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 14:26 +0100
Re: memcpy not memcpying? Keith Thompson <kst-u@mib.org> - 2019-11-01 10:22 -0700
Re: memcpy not memcpying? Bart <bc@freeuk.com> - 2019-11-01 19:44 +0000
Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 21:31 +0100
Re: memcpy not memcpying? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-01 09:39 -0400
Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 14:42 +0100
Re: memcpy not memcpying? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-01 09:48 -0400
Re: memcpy not memcpying? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-01 06:47 -0700
Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 14:58 +0100
Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 10:22 -0400
Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 18:38 +0100
Re: memcpy not memcpying? scott@slp53.sl.home (Scott Lurndal) - 2019-11-01 17:54 +0000
Re: memcpy not memcpying? Autist <autist69@gmail.com> - 2019-11-01 20:24 +0100
Re: memcpy not memcpying? DFS <nospam@dfs.com> - 2019-11-01 15:24 -0400
Re: memcpy not memcpying? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-01 23:19 +0000
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Autist <autist69@gmail.com> |
|---|---|
| Date | 2019-11-04 12:56 +0100 |
| Message-ID | <qpp3kh$l43$1@news.albasani.net> |
| In reply to | #147568 |
> I don't. C is a terrible choice of language for gui programming (on > Windows or Linux). C is a terrible language at all; everythin in C makes much work.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-04 09:50 -0500 |
| Message-ID | <qppdr3$6gl$1@dont-email.me> |
| In reply to | #147571 |
On 11/4/19 6:56 AM, Autist wrote: >> I don't. C is a terrible choice of language for gui programming (on >> Windows or Linux). > > C is a terrible language at all; everythin in C makes much work. If you feel that way, why bother posting to comp.lang.c?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-11-04 20:26 +0000 |
| Message-ID | <EP%vF.8690$BF1.3467@fx26.iad> |
| In reply to | #147577 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: >On 11/4/19 6:56 AM, Autist wrote: >>> I don't. C is a terrible choice of language for gui programming (on >>> Windows or Linux). >> >> C is a terrible language at all; everythin in C makes much work. > >If you feel that way, why bother posting to comp.lang.c? Starts with T, ends will -ling.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-11-04 04:34 -0800 |
| Message-ID | <d52c7a23-86f2-48fe-9f52-24476fb39fcb@googlegroups.com> |
| In reply to | #147568 |
On Monday, 4 November 2019 10:00:22 UTC, David Brown wrote: > On 04/11/2019 00:28, Bart wrote: > > > > > But I can't imagine when someone writing Haskell would want to bother > > with anything other than "v". > > You base this on your vast experience with Haskell programming? > Javascript (I actually used a variant called tiscript) has a %v format flag to its printf, which dumps an entire object in JSON. It's useful for debugging, and for communicating with non-Javascript JSON aware modules, in my case, C++. But you still need the C format flags for printf to produce formatted output for non-debugging purposes.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-04 13:05 +0000 |
| Message-ID | <TmVvF.18103$oK6.14009@fx07.am4> |
| In reply to | #147573 |
On 04/11/2019 12:34, Malcolm McLean wrote:
> On Monday, 4 November 2019 10:00:22 UTC, David Brown wrote:
>> On 04/11/2019 00:28, Bart wrote:
>>
>>>
>>> But I can't imagine when someone writing Haskell would want to bother
>>> with anything other than "v".
>>
>> You base this on your vast experience with Haskell programming?
>>
> Javascript (I actually used a variant called tiscript) has a %v format
> flag to its printf, which dumps an entire object in JSON.
>
> It's useful for debugging, and for communicating with non-Javascript
> JSON aware modules, in my case, C++. But you still need the C format
> flags for printf to produce formatted output for non-debugging
> purposes.
>
Script languages actually don't really need such codes at all. For
example, instead of:
print("%v",X)
You can just do (I don't know what JS print looks like):
print(dumptoJSON(x))
with that function returning a string object which is then just printed
as a regular string, or sent to a file, or whatever you want to do with it.
It was somewhat a surprise to me that Haskell still needed such quaint
gimmicks as format codes.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-04 14:09 +0000 |
| Message-ID | <878sovlolz.fsf@bsb.me.uk> |
| In reply to | #147574 |
Bart <bc@freeuk.com> writes: > It was somewhat a surprise to me that Haskell still needed such quaint > gimmicks as format codes. It doesn't. Are you running for office? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-04 15:11 +0000 |
| Message-ID | <7dXvF.103687$NI41.98794@fx12.am4> |
| In reply to | #147575 |
On 04/11/2019 14:09, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> It was somewhat a surprise to me that Haskell still needed such quaint >> gimmicks as format codes. > > It doesn't. OK, the codes apparently are needed for its Text.Printf function, which is very strongly modelled on C's printf, other than it doesn't do pointer types, and has the "%v" option that sets a default format like my "%?" proposal. It even still has these modifiers: hh Int8 h Int16 l Int32 ll Int64 Which here, at least, are associated with specific widths, while C is reluctant to pin them down. (I don't know Haskell's type system so don't know why these are actually necessary. I would have expected any packed narrow types such as Int16 to be promoted to something like Int64 when used in any expression, then you only need "%d".)
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-11-04 15:15 +0000 |
| Message-ID | <LgXvF.122687$hk3.90169@fx19.am4> |
| In reply to | #147579 |
On 2019-11-04, Bart <bc@freeuk.com> wrote: > On 04/11/2019 14:09, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> It was somewhat a surprise to me that Haskell still needed such quaint >>> gimmicks as format codes. >> >> It doesn't. > > OK, the codes apparently are needed for its Text.Printf function, which > is very strongly modelled on C's printf, other than it doesn't do > pointer types, and has the "%v" option that sets a default format like > my "%?" proposal. > > It even still has these modifiers: > > hh Int8 > h Int16 > l Int32 > ll Int64 > > Which here, at least, are associated with specific widths, while C is > reluctant to pin them down. > > (I don't know Haskell's type system so don't know why these are actually > necessary. I would have expected any packed narrow types such as Int16 > to be promoted to something like Int64 when used in any expression, then > you only need "%d".) Haskell does not have implicit conversion... actually Haskell does not have any conversion, nor casts... > -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-04 15:43 +0000 |
| Message-ID | <87wocfk5oo.fsf@bsb.me.uk> |
| In reply to | #147579 |
Bart <bc@freeuk.com> writes: > On 04/11/2019 14:09, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> It was somewhat a surprise to me that Haskell still needed such quaint >>> gimmicks as format codes. >> >> It doesn't. > > OK, the codes apparently are needed for its Text.Printf function, Yes. There's a printf function for when it's the most convenient way to generate output. Obviously format codes are needed for a printf function. > It even still has these modifiers: > > hh Int8 > h Int16 > l Int32 > ll Int64 > > Which here, at least, are associated with specific widths, while C is > reluctant to pin them down. That's is not what's going on, but the details are way off-topic. > (I don't know Haskell's type system so don't know why these are > actually necessary. I would have expected any packed narrow types such > as Int16 to be promoted to something like Int64 when used in any > expression, then you only need "%d".) Even more off-topic. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-03 20:20 +0000 |
| Message-ID | <0EGvF.11497$xi6.1267@fx40.am4> |
| In reply to | #147543 |
On 03/11/2019 16:46, David Brown wrote: > On 03/11/2019 14:27, Bart wrote: >> I suggested a format "%?" where the compiler fills in the default type >> where the format string is visible. Which is nearly always. > > That opens a range of complications. What should happen when the format > string is not a string literal? In internationalised programs, it is > common for the format string to be the result of a table lookup. Then they are doing things wrong. There are enough problems with the printf-format scheme without burying thousands of very specific format codes within strings inside external files, a long way from the source code. An awful lot of maintenance to do with some types change! How many messages will have embedded values anyway? I've been through this, and it was enough to split up translatable messages.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-11-03 14:37 +1300 |
| Message-ID | <h26pamFa2cqU5@mid.individual.net> |
| In reply to | #147520 |
On 03/11/2019 12:47, Bart wrote: > On 02/11/2019 22:59, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: > >> And yet you continue to whine about it. Have fun with that. > > David Brown was trying to put the blame for the non-support of zu on > tcc, for which he has demonstrated a very poor opinion. > > I'm pointing out that my 500x bigger gcc installation has exactly same > problem. Which is an old Windows library... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-03 11:01 +0000 |
| Message-ID | <KsyvF.21664$u64.16998@fx35.am4> |
| In reply to | #147524 |
On 03/11/2019 01:37, Ian Collins wrote: > On 03/11/2019 12:47, Bart wrote: >> On 02/11/2019 22:59, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >> >>> And yet you continue to whine about it. Have fun with that. >> >> David Brown was trying to put the blame for the non-support of zu on >> tcc, for which he has demonstrated a very poor opinion. >> >> I'm pointing out that my 500x bigger gcc installation has exactly same >> problem. > > Which is an old Windows library... Even for the recommended, freshly installed mingw-w64. Why is that? mingw contains over 900 lib*.a (being a MINimalistic distribution...). I looked for the ones with "crt" in the name, and randomly tried using those using the -l flag. "%zu" worked when I used -lucrtbase. But I haven't tried any bigger programs than that. Using ucrtbase.dll with other compilers doesn't work (eg. no 'printf', but there are multiple functions like __stdio_common_vfprintf.) So it is not really a solution as I can't use something that only works with gcc and only when using -lucrtbase; what an imposition just to use 'printf' properly.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-03 04:03 -0800 |
| Message-ID | <804c44f4-15ed-461f-bba8-84846d78e784@googlegroups.com> |
| In reply to | #147530 |
On Sunday, 3 November 2019 13:02:11 UTC+2, Bart wrote: > On 03/11/2019 01:37, Ian Collins wrote: > > On 03/11/2019 12:47, Bart wrote: > >> On 02/11/2019 22:59, Keith Thompson wrote: > >>> Bart <bc@freeuk.com> writes: > >> > >>> And yet you continue to whine about it. Have fun with that. > >> > >> David Brown was trying to put the blame for the non-support of zu on > >> tcc, for which he has demonstrated a very poor opinion. > >> > >> I'm pointing out that my 500x bigger gcc installation has exactly same > >> problem. > > > > Which is an old Windows library... > > Even for the recommended, freshly installed mingw-w64. Why is that? There are three factors and all of those likely apply: 1) It is somewhat your own fault. Perhaps you have somehow configured your system and its environment variables so that even freshly installed mingw64 does run differently than on majority of other systems. 2) Both its makers and other users somewhat don't care. It is engineering tool after all and so its average user gets it working and is requesting other things and therefore its makers are busy dealing with those other issues. 3) It is somewhat intentional. C programs made by little babies or fools may harm the system more than help with anything and so the tiny difficulties are left there for preventing babies and fools from using C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-03 12:52 +0000 |
| Message-ID | <c4AvF.100887$m0L.46810@fx15.am4> |
| In reply to | #147534 |
On 03/11/2019 12:03, Öö Tiib wrote: > On Sunday, 3 November 2019 13:02:11 UTC+2, Bart wrote: >> On 03/11/2019 01:37, Ian Collins wrote: >>> On 03/11/2019 12:47, Bart wrote: >>>> On 02/11/2019 22:59, Keith Thompson wrote: >>>>> Bart <bc@freeuk.com> writes: >>>> >>>>> And yet you continue to whine about it. Have fun with that. >>>> >>>> David Brown was trying to put the blame for the non-support of zu on >>>> tcc, for which he has demonstrated a very poor opinion. >>>> >>>> I'm pointing out that my 500x bigger gcc installation has exactly same >>>> problem. >>> >>> Which is an old Windows library... >> >> Even for the recommended, freshly installed mingw-w64. Why is that? > > There are three factors and all of those likely apply: > > 1) It is somewhat your own fault. Perhaps you have somehow configured > your system and its environment variables so that even freshly > installed mingw64 does run differently than on majority of other > systems. In other words, it's complicated. When I use my compiler, it's one file (bcc.exe which incorporates all the headers) plus the library (msvcrt.dll). Literally nothing else. There is no ambiguity about which library is being used. There are no environment variables, and there are no paths to sort out. This minimises the ways in which things can go wrong. (Not by accident; this was by design.) The next simplest C compiler I have is tcc. But while the executable is small, there are multiple header files (90) plus 3 .a files, plus 4 .def files (specific to tcc), the name of one of which suggests that it is also dependent on msvcrt.dll. Yet, it also accepts the -lucrtbase option, but which seems to do nothing. It is not quite as clear-cut. > 3) It is somewhat intentional. C programs made by little babies or > fools may harm the system more than help with anything and so the > tiny difficulties are left there for preventing babies and fools > from using C. Or it could just be a bug. After all, if it is within the power of the compiler to link either an old or new C library, why would it choose an old one? Even if you compile with -std=c11. Here are the default libraries that gcc passes through as options to its linker: -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt Notice that mingw32, gcc, gcc_eh, moldname, mingwex and msvcrt are specified twice. That's pretty good going. If you specify -lucrtbase, the magic needed to support zu, then it just prepends it to that list; msvcrt is still included - twice.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-11-03 23:34 -0800 |
| Message-ID | <dc4b9d4c-0c34-471b-adfb-47ceb93747df@googlegroups.com> |
| In reply to | #147535 |
On Sunday, 3 November 2019 14:52:35 UTC+2, Bart wrote: > > Here are the default libraries that gcc passes through as options to its > linker: > > -lmingw32 > -lgcc > -lgcc_eh > -lmoldname > -lmingwex > -lmsvcrt > -lpthread > -ladvapi32 > -lshell32 > -luser32 > -lkernel32 > -liconv > -lmingw32 > -lgcc > -lgcc_eh > -lmoldname > -lmingwex > -lmsvcrt > > Notice that mingw32, gcc, gcc_eh, moldname, mingwex and msvcrt are > specified twice. That's pretty good going. If you specify -lucrtbase, > the magic needed to support zu, then it just prepends it to that list; > msvcrt is still included - twice. That can be to resolve circular dependencies.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-04 09:36 +0000 |
| Message-ID | <ziSvF.32371$_d3.18643@fx38.am4> |
| In reply to | #147566 |
On 04/11/2019 07:34, Öö Tiib wrote: > On Sunday, 3 November 2019 14:52:35 UTC+2, Bart wrote: >> >> Here are the default libraries that gcc passes through as options to its >> linker: >> >> -lmingw32 >> -lgcc >> -lgcc_eh >> -lmoldname >> -lmingwex >> -lmsvcrt >> -lpthread >> -ladvapi32 >> -lshell32 >> -luser32 >> -lkernel32 >> -liconv >> -lmingw32 >> -lgcc >> -lgcc_eh >> -lmoldname >> -lmingwex >> -lmsvcrt >> >> Notice that mingw32, gcc, gcc_eh, moldname, mingwex and msvcrt are >> specified twice. That's pretty good going. If you specify -lucrtbase, >> the magic needed to support zu, then it just prepends it to that list; >> msvcrt is still included - twice. > > That can be to resolve circular dependencies. > That sounds most likely. When compiling modules A.c and B.c where each calls functions in the other, you don't have A.o and B.o submitted twice to the linker. And if it really was an issue, then ld could simply repeat the whole list of libraries internally.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-04 16:20 +0000 |
| Message-ID | <rdYvF.104608$NI41.63855@fx12.am4> |
| In reply to | #147567 |
On 04/11/2019 09:36, Bart wrote: > On 04/11/2019 07:34, Öö Tiib wrote: >> On Sunday, 3 November 2019 14:52:35 UTC+2, Bart wrote: >>> >>> Here are the default libraries that gcc passes through as options to its >>> linker: >>> >>> -lmingw32 >>> -lgcc >>> -lgcc_eh >>> -lmoldname >>> -lmingwex >>> -lmsvcrt >>> -lpthread >>> -ladvapi32 >>> -lshell32 >>> -luser32 >>> -lkernel32 >>> -liconv >>> -lmingw32 >>> -lgcc >>> -lgcc_eh >>> -lmoldname >>> -lmingwex >>> -lmsvcrt >>> >>> Notice that mingw32, gcc, gcc_eh, moldname, mingwex and msvcrt are >>> specified twice. That's pretty good going. If you specify -lucrtbase, >>> the magic needed to support zu, then it just prepends it to that list; >>> msvcrt is still included - twice. >> >> That can be to resolve circular dependencies. >> > > That sounds most likely. Unlikely.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-11-04 07:46 +1300 |
| Message-ID | <h28lk2Fa2cqU9@mid.individual.net> |
| In reply to | #147530 |
On 04/11/2019 00:01, Bart wrote: > On 03/11/2019 01:37, Ian Collins wrote: >> On 03/11/2019 12:47, Bart wrote: >>> On 02/11/2019 22:59, Keith Thompson wrote: >>>> Bart <bc@freeuk.com> writes: >>> >>>> And yet you continue to whine about it. Have fun with that. >>> >>> David Brown was trying to put the blame for the non-support of zu on >>> tcc, for which he has demonstrated a very poor opinion. >>> >>> I'm pointing out that my 500x bigger gcc installation has exactly same >>> problem. >> >> Which is an old Windows library... > > Even for the recommended, freshly installed mingw-w64. Why is that? I have no idea, I don't use Windows. I don't, but many of my colleagues do use Visual Studio and our code base plenty of uses of %zu, so there must be more up to date "native" Windows libraries. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-11-03 12:26 -0800 |
| Message-ID | <lnr22o671e.fsf@kst-u.example.com> |
| In reply to | #147549 |
Ian Collins <ian-news@hotmail.com> writes:
> On 04/11/2019 00:01, Bart wrote:
>> On 03/11/2019 01:37, Ian Collins wrote:
>>> On 03/11/2019 12:47, Bart wrote:
>>>> On 02/11/2019 22:59, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> And yet you continue to whine about it. Have fun with that.
>>>>
>>>> David Brown was trying to put the blame for the non-support of zu on
>>>> tcc, for which he has demonstrated a very poor opinion.
>>>>
>>>> I'm pointing out that my 500x bigger gcc installation has exactly same
>>>> problem.
>>>
>>> Which is an old Windows library...
>>
>> Even for the recommended, freshly installed mingw-w64. Why is that?
>
> I have no idea, I don't use Windows. I don't, but many of my colleagues
> do use Visual Studio and our code base plenty of uses of %zu, so there
> must be more up to date "native" Windows libraries.
Confirmed, with Visual Studio 2019, printf does support "%zu".
According to <https://stackoverflow.com/a/44055215/827263>, support for
"%zu" was introduced in VS2013 (_MSC_VER >= 1800).
Bart probably has an older version of Microsoft's C runtime. Of course
it has nothing to do with the compiler he's using. Presumably a fresh
installation of MinGW-w64 will use whatever existing C runtime is
already on the system.
(BTW, I'll be using Visual Studio in my new job. Speaking of which,
**I got a new job!**)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-03 17:31 +0100 |
| Message-ID | <qpmvck$6g9$1@dont-email.me> |
| In reply to | #147520 |
On 03/11/2019 00:47, Bart wrote:
> On 02/11/2019 22:59, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>> And yet you continue to whine about it. Have fun with that.
>
> David Brown was trying to put the blame for the non-support of zu on
> tcc, for which he has demonstrated a very poor opinion.
>
C99 requires that "%zu" be supported in printf. A C implementation that
does not support it does not support C99 - and I am unimpressed by any
modern C implementation that fails to support something that simple in C99.
tcc is, however, a /compiler/ - not a C implementation. The failure to
support "%zu" typically lies in the library - it is MS's C run-time
library that I have complained about, not the compiler. (tcc on my
Linux system has no problem with "%zu").
In general, however, my opinion of tcc is that it is an interesting
project and an impressive amount of compiler for the size, but when size
doesn't matter (and it very rarely does), it is not remotely as good a C
development tool as the major compilers.
But looking back at the posts in this thread, I see I mixed up "tcc" and
"tdm". The OP "DFS" had previously discussed gcc several times, and I
assumed he had been talking about "tdm" (which is a gcc-based C
implementation for Windows that uses MS's C run-time DLL library),
rather than "tcc" (which does not claim to be more than a compiler, and
does not claim to support anything beyond C90). My apologies for the
mistake and the confusion.
> I'm pointing out that my 500x bigger gcc installation has exactly same
> problem.
>
The emphasis being on "my" here - other people have gcc installations
without that problem. You seem to have a special talent for getting
this kind of thing wrong and mixed up, but I believe it is mainly due to
determined effort on your part.
>> Earlier today, I installed MinGW-w64. "%zu" worked correctly.
>> If you don't care why, I certainly don't.
>
> That's nice. But I'm not prepared to trawl through my 26,000 files (for
> tdm and mingw64) to try to figure what's going on. That's not my job.
>
> I tell gcc - and its bundled headers, assembler, linkers and what-not -
> that I want to call printf("%zu",sizeof(T)), it's its job to make it work.
>
I suggest you complain to your vendor and demand your money back.
>> <stdint.h> defines a large number of integer types. Defining printf and
>> scanf formats for *all* of them would, I think, have been an undue
>> burden.
>
> MS libraries support I64 and I32 width specifiers (as in "%I64d"). That
> wouldn't have been a bad starting point.
>
It would have been a perfectly reasonable alternative starting point,
yes - if they had existed at the time. I might have the timeline
details a bit wrong, but while the C committee was deciding on this
stuff, MS was still in a world of 16-bit DOS with a partly 32-bit gui
shell on top.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web