Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: memcpy not memcpying? Date: Sat, 02 Nov 2019 18:22:32 -0700 Organization: None to speak of Lines: 74 Message-ID: References: <2LVuF.7$BF1.0@fx26.iad> <6KfvF.57888$rJ1.57717@fx01.am4> <0DivF.23103$Q26.16540@fx34.am4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="885fb82be1e12b29daafc6f7a8ced528"; logging-data="3567"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Ng+ClAR6fj01TyTQ4kHvc" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:gW+YJrUoxvgnYWWMQvPRO3nw9As= sha1:Ecr5SyHhP3Dl8kGHrnEL/Z0j5Rc= Xref: csiph.com comp.lang.c:147521 Bart writes: > On 02/11/2019 22:59, Keith Thompson wrote: >> Bart 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. He was not. He was pointing out, quite correctly, that supporting "%zu" is not tcc's job any more than it's gcc's job. The problem is in the runtime library that's part of whatever implementation you're using that includes tcc as its compiler component. > I'm pointing out that my 500x bigger gcc installation has exactly same > problem. Yes, I understood that the first time you said it. Your 500x bigger installation is using a C library that doesn't support "%zu". >> 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. Was I unclear? Nobody is asking you to trawl through anything. You've said you don't care, and I'm not even saying you should. > 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. Bart, you know what "gcc" is. And again, you've already said you don't care why "%zu" doesn't work for you. Someone who really didn't care would have stopped talking about it by now. >> 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. Maybe -- but the MS libraries can assume that the implementation supports integer types of exactly 32 and 64 bits. The C standard does not make that assumption. For example, defines macros PRId32, PRIdLEAST32, and PRIdFAST32 for int32_t, int_least32_t, and int_fast32_t, respectively. The type int32_t is optional; int_least32_t and int_fast32_t are mandatory. The standard has to cover more possible target systems than Windows does (or Linux, or POSIX), including systems that may not exist yet. You can see a list of the macros in N1570 7.8.1. Some of them exist for each width, at least 8, 16, 32, and 64, for a total of 84 PRI* macros and 70 SCN* macros if I've counted correctly. (Exotic implementations might support other widths, or might not support all of 8, 16, 32, and 64 for the exact-width types.) You *could* implement those 154 possibilities directly in the *printf and *scanf functions, with distinct syntaxes in the format strings, but I prefer the way it's done in the standard. I'm not saying that the PRI* and SCN* macros are ideal, but I can't think of a cleaner way to define them while supporting the same functionality. No doubt your private language does it better, but that doesn't help C. (I've just noticed that there are macros for the [u]intmax_t types, which are redundant with the 'j' length modifier. I don't think that redundancy is a problem.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */