Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!news.dfncis.de!not-for-mail From: =?ISO-8859-1?Q?Hans-Bernhard_Br=F6ker?= Newsgroups: comp.std.c Subject: Re: PRI* considered harmful Date: Sat, 09 Jul 2011 20:59:32 +0200 Lines: 37 Message-ID: <97rmoaFc7oU1@mid.dfncis.de> References: <87mxgqhk3x.fsf@once.weird.com> <8762ndhnfs.fsf@once.weird.com> <87oc15g10i.fsf@once.weird.com> <87zkkpef5z.fsf@once.weird.com> <87r560c6pp.fsf@once.weird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.dfncis.de dBKDq+nJXnGLtxvUv75p+QVfMRLLGuFJak3o67qTucb1hB87z5BW0yOJf4 Cancel-Lock: sha1:bWGrl9ZNsIYww07P3Q/w8cYtvxw= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: <87r560c6pp.fsf@once.weird.com> Xref: x330-a1.tempe.blueboxinc.net comp.std.c:685 On 09.07.2011 08:24, Greg A. Woods wrote: > Keith Thompson writes: >> So don't use them. > It's not _my_ problem -- I try not to use the PRI* macros. :-) You appear to have that bass ackwards. Your problem is that you're trying so hard not to use them that you never properly found out whether or not there's anything wrong with their specification. Instead, you rely on random snippets of second- and third-hand knowledge to base a wild claim on. > It's just that I've seen many references to PRId32 on Linux, including > online manual pages, which show it as "ld" So what? "ld" _can_ be a valid definition for that macro. It's up to you, as the person making the big claims here, to prove that on the systems you found that definition, it's an incorrect one. > Well, for me personally (as opposed to all those I see trying to use > PRI* poorly), the problem extends to every other typedef name that one > might define in any application which one hopes to be portable and easy > to maintain. Defining such stuff from scratch is never portable. It cannot be. _Using_ portable definitions makes portable code. That's why int32_t and its colleagues exists. Their definition is unavoidably implementation-specific. > The reason I've harped on PRI* is that their existance would also be > entirerly unnecessary were something like my proposal implemented, A proposal that, the way it completely breaks just about every existing implementation, not to mention a seriously big number of existing user programs for no visible benefit, really does need to be rejected flat out.