Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #147519
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: memcpy not memcpying? |
| Date | 2019-11-02 15:59 -0700 |
| Organization | None to speak of |
| Message-ID | <ln36f57ul5.fsf@kst-u.example.com> (permalink) |
| References | (7 earlier) <6KfvF.57888$rJ1.57717@fx01.am4> <qpkakk$gq7$1@dont-email.me> <0DivF.23103$Q26.16540@fx34.am4> <ln7e4i6o0y.fsf@kst-u.example.com> <OcmvF.87562$Pt2.3193@fx23.am4> |
Bart <bc@freeuk.com> writes:
> On 02/11/2019 20:06, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> TDM is apparently based on MinGW, an implementation that uses the gcc
>> compiler and the Microsoft C runtime library. No, it hasn't bothered to
>> include an up-to-date C runtime, preferring for whatever reason to use
>> the existing Microsoft C runtime. Its failure to support "%zu" has
>> nothing to do with gcc.
>
[21 lines deleted]
>
>> Perhaps "runtime environment" isn't the best description. It is,
>> as you know perfectly well,
>
> Actually, no I don't. People have gone to great pains here in the past
> to explain the difference between C compilers, standard header files,
> necessary utilities such as assemblers and linkers, and standard
> libraries, and that obtaining a C compiler need not imply that you will
> get anything else necessary to turn C source to an executable that will
> properly deal with "%zu".
A *compiler* doesn't implement "%zu". A *library* does. An
implementation includes a compiler, a library, and some other
components.
Some implementations (like lcc-win) are packaged with a tightly
integrated compiler and library, neither of which is intended to be used
separately. Others (such as the common gcc/glibc implementation on
Linux-based system, or clang/glibc, or gcc/newlib, etc.) are put
together from separately developed components -- and sometimes the
integration is imperfect.
>> Naturally you seize on a single poorly worded description so you
>> can spread confusion.
>
> I /am/ confused. The description can be SO much better:
>
> "This mingw64 download includes the gcc compiler, a set of standard
> include files, its own C library, the 'as' assembler needed by gcc, the
> 'ld' linker, and a make utility"
That appears to be a correct description. And yet you claim to be
confused.
> Or not, as the case may be. (There is, for example, something called
> 'mingw32-make.exe'; is that make? I really don't know.)
Yes. I just installed it, and running it with the "--version" option
prints
GNU Make 4.2.1
Built for x86_64-w64-mingw32
...
>> Yes the old MinGW's use of the Microsoft C library is a problem.
>> That problem was corrected by the introduction of MinGW-w64.
>> (I'm not entirely sure to what extent MinGW-w64 is, or is intended
>> to be, a replacement for MinGW.)
>
> You would think that a 660MB download of gcc version 8.1.0, which is
> reasonably recent, would have included new libraries.
>
>> I don't know why it doesn't work for you. My guess is that either
>> you're not using the gcc provided by MinGW-w64, or you've managed
>> to use it along with the Microsoft runtime library. It does work
>> for me. What does "gcc --version" print?
>
> It shows:
>
> gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
>
> downloaded today. And as I said, I hide the tdm version, but which was
> also 8.1.0 anyway.
OK, that appears to be the right version of gcc. Again, I don't know
why you're having problems.
>> Normally I'd suggest that you ask for help resolving the issue,
>
> I don't want to resolve it because I don't care.
Excellent.
> gcc (gnu, mingw-W64
> whatever) is just too complex, THAT is the problem. Sorting out one
> tiny, tiny aspect (%zu support on one installation) will not fix that.
And yet you continue to whine about it. Have fun with that.
Earlier today, I installed MinGW-w64. "%zu" worked correctly.
If you don't care why, I certainly don't.
> But I do wonder who came up with the idea of "%zu" for size_t, which
> requires these changes to decades-old *printf routines, while the
> equivalents for int64_t etc have to make do with those PRi64d macros.
That's actually not a bad question. Since you asked, I'll pretend
that you care about the answer. You probably don't, but others
might.
size_t, ptrdiff_t, and the [u]intN_t types declared in <stdint.h>
are all integer types, almost certainly typedefs for predefined
types chosen in an implementation-defined manner. The C90 version
of printf didn't support formats for types other than the predefined
ones.
According to the C99 Rationale:
<inttypes.h> was derived from the header of the same name found
on several existing 64-bit systems. The Committee debated other
methods for specifying integer sizes and other characteristics,
but in the end decided to standardize existing practice rather
than innovate in this area. (See also §7.18 <stdint.h>.)
<inttypes.h> defines a number of integer types and macros for *printf
and *scanf format conversions. The Rationale doesn't mention the latter
-- nor does it mention the j, z, and t length modifiers (for
[u]intmax_t, size_t, and ptrdiff_t, respectively) that were also added
in C99.
The type size_t and ptrdiff_t already existed C90, but with no clean way
to print them. Adding just three new length modifiers to support them
and [u]intmax_t seems like a minor burden. The *printf and *scanf
functions has to be modified anyway, to support long long and a few
other enhancements added in C99. I presume "%zu" was an invention of
the committee.
<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. The burden on library implementers would have been minor, but
defining the syntax in the tiny language of format strings and expecting
programmers to learn all the details would have been more difficult.
Sure, C99 *could* have defined macros for size_t, ptrdiff_t, and
[u]intmax_t formats similar to the ones defined for [u]intN_t et al.
That would have been more uniform, but IMHO less convenient. I
personally *like* being able to write "%zu" to print a size_t value,
without having to include a header that defines a macro that expands to
whatever format would be used for whichever type size_t is defined as.
And the macros defined in <stdint.h> (which I personally find ugly, but
I don't know a good way to de-uglify them) were apparently invented
outside the standard process, and incorporated into C99.
If you expect C to be completely consistent, you're going to be
disappointed. But in this particular case, I think the tradeoff (new
modifiers for a handful of types, macros for the rest) is a perfectly
reasonable one.
--
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 */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web