Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Q: stdint format specifiers |
| Date | 2016-08-04 14:19 -0700 |
| Organization | None to speak of |
| Message-ID | <lnziosz0xx.fsf@kst-u.example.com> (permalink) |
| References | <nnvpf7$1ojc$1@gioia.aioe.org> <282c43f4-9e51-4c3c-9552-6703c60df230@googlegroups.com> <ln8twc1fpw.fsf@kst-u.example.com> <ad7f21a6-cd3b-450b-b625-a64fd3f4bdbd@googlegroups.com> |
supercat@casperkitty.com writes:
> On Thursday, August 4, 2016 at 2:44:52 PM UTC-5, Keith Thompson wrote:
>> Without that ability, it could use "%ld" for any argument of type
>> long, whether it was defined using the name "long" or the name
>> "int32_t". But then the resulting code (assuming you're trying
>> to generate C source code) wouldn't be portable; it could fail
>> when compiled for a system where int32_t is an alias for int, and
>> long is 64 bits. (Unless you regenerate the source code for each
>> target system; is that an option?)
>
> From what I can tell, the fundamental purpose of all the PRI_* macros is
> to make code that uses types like uint32_t behave in a fashion independent
> of the size of the built-in integer types; the main reason one would want
> to convert code from using %ld to using those macros is to facilitate
> migration of that code to other systems.
Right. I wasn't discussing the purpose of the PRI_* macros, just the
problems inherent in automatically generating code that uses them.
Strictly speaking it's not just the *sizes* of the built-in types. For
example, even if int and long both happen to be 32 bits, using "%d" with
a long argument or "%ld" with an int argument still has undefined
behavior (regardless of whether the declaration used "int", "int32_t",
or some other name). The symptom of the UB is likely to be that it
"works", but it's still UB.
> If integer types change, some
> format specifiers will need to change while others won't, and there's no
> easy way to specify which.
Which is pretty much what I said.
> BTW, many such headaches could have been avoided if the Standard had made
[snip]
--
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"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Q: stdint format specifiers Johann Klammer <klammerj@NOSPAM.a1.net> - 2016-08-04 18:11 +0200
Re: Q: stdint format specifiers supercat@casperkitty.com - 2016-08-04 09:53 -0700
Re: Q: stdint format specifiers Keith Thompson <kst-u@mib.org> - 2016-08-04 12:44 -0700
Re: Q: stdint format specifiers Johann Klammer <klammerj@NOSPAM.a1.net> - 2016-08-04 22:57 +0200
Re: Q: stdint format specifiers supercat@casperkitty.com - 2016-08-04 14:11 -0700
Re: Q: stdint format specifiers Keith Thompson <kst-u@mib.org> - 2016-08-04 14:19 -0700
Re: Q: stdint format specifiers supercat@casperkitty.com - 2016-08-04 15:08 -0700
Re: Q: stdint format specifiers Keith Thompson <kst-u@mib.org> - 2016-08-04 15:26 -0700
Re: Q: stdint format specifiers Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:19 -0700
Re: Q: stdint format specifiers supercat@casperkitty.com - 2016-08-05 08:04 -0700
Re: Q: stdint format specifiers Keith Thompson <kst-u@mib.org> - 2016-08-05 08:26 -0700
csiph-web