Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #10572 > unrolled thread
| Started by | Robert Roland <fake@ddress.no> |
|---|---|
| First post | 2012-11-24 17:41 +0100 |
| Last post | 2012-11-26 00:08 +0000 |
| Articles | 20 on this page of 153 — 47 participants |
Back to article view | Back to comp.arch.embedded
Getting started with AVR and C Robert Roland <fake@ddress.no> - 2012-11-24 17:41 +0100
Re: Getting started with AVR and C hamilton <hamilton@nothere.com> - 2012-11-24 09:55 -0700
Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-25 10:39 +0100
Re: Getting started with AVR and C Rene <a@b.c> - 2012-11-24 18:03 +0100
Re: Getting started with AVR and C Rene <a@b.c> - 2012-12-10 13:21 +0100
Re: Getting started with AVR and C Christopher Head <chead@is.invalid> - 2012-12-10 18:33 -0800
Re: Getting started with AVR and C Rene <a@b.c> - 2012-12-11 12:34 +0100
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.please> - 2012-11-24 12:44 -0600
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-24 11:12 -0800
Re: Getting started with AVR and C mike <ham789@netzero.net> - 2012-11-24 11:28 -0800
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-24 11:42 -0800
Re: Getting started with AVR and C mike <ham789@netzero.net> - 2012-11-25 07:01 -0800
Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-25 20:14 +0100
Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-25 03:18 +0700
Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-25 04:18 +0700
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-11-24 17:09 -0500
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-24 22:12 +0000
Re: Getting started with AVR and C Dave Nadler <drn@nadler.com> - 2012-11-24 21:01 -0800
statement / expression contexts in C Ivan Shmakov <oneingray@gmail.com> - 2012-11-28 12:54 +0700
Re: Getting started with AVR and C Ivan Shmakov <oneingray@gmail.com> - 2012-11-28 13:37 +0700
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-28 14:49 +0000
Re: Getting started with AVR and C Frank Miles <fpm@u.washington.edu> - 2012-11-28 17:53 +0000
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-28 18:05 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 12:56 -0600
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-28 21:45 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 15:55 -0600
Re: Getting started with AVR and C David Brown <david.brown@removethis.hesbynett.no> - 2012-11-29 01:35 +0100
Re: Getting started with AVR and C Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-11-29 01:47 +0100
Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:24 +0100
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 01:18 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 20:07 -0600
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:23 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 11:01 -0500
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 19:19 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 14:32 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 11:44 -0800
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 21:23 +0000
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 18:15 -0800
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-30 09:26 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 13:22 -0800
Re: Getting started with AVR and C me@linnix.info-for.us - 2012-11-30 14:10 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 15:16 -0800
Re: Getting started with AVR and C Mel Wilson <mwilson@the-wire.com> - 2012-11-30 17:36 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-30 15:18 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-01 10:08 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 00:45 -0800
Re: Getting started with AVR and C Ed Beroset <beroset@mindspring.com> - 2012-12-01 08:00 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 13:22 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-01 17:33 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-01 17:43 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-02 14:13 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-04 20:34 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-04 18:25 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-05 07:55 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:11 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-05 07:52 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-05 11:02 -0500
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 21:28 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:21 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 23:05 +0200
Re: Getting started with AVR and C Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2012-12-05 23:22 +0200
Re: Getting started with AVR and C Niklas Holsti <niklas.holsti@tidorum.invalid> - 2012-12-06 00:00 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 12:17 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-05 23:10 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 15:25 -0800
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-06 07:15 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 21:52 -0800
Re: Getting started with AVR and C Lanarcam <lanarcam1@yahoo.fr> - 2012-12-06 20:59 +0100
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-06 12:38 -0800
Re: Getting started with AVR and C George Neuner <gneuner2@comcast.net> - 2012-12-06 20:39 -0500
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-06 22:31 -0500
Re: Getting started with AVR and C Mel Wilson <mwilson@the-wire.com> - 2012-12-05 16:32 -0500
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 15:25 -0800
Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-05 17:04 -0800
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-12-05 22:01 -0800
Re: Getting started with AVR and C Ian Malcolm <See.My.Sig.for.email@totally.invalid> - 2012-12-06 14:05 +0000
Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-06 10:28 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-06 16:58 -0800
Re: Getting started with AVR and C Mark Borgerson <mborgerson@comcast.net> - 2012-12-06 07:34 -0800
Re: Getting started with AVR and C Walter Banks <walter@bytecraft.com> - 2012-12-06 10:55 -0500
Re: Getting started with AVR and C Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-12-06 11:11 -0500
Re: Getting started with AVR and C Rocky <RobertGush@gmail.com> - 2012-12-06 21:38 -0800
Re: Getting started with AVR and C dp <dp@tgi-sci.com> - 2012-12-07 03:49 -0800
Re: Getting started with AVR and C Robert Wessel <robertwessel2@yahoo.com> - 2012-12-01 02:58 -0600
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-01 17:28 +0200
Re: Getting started with AVR and C Robert Wessel <robertwessel2@yahoo.com> - 2012-12-01 11:55 -0600
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-11-29 22:17 +0200
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 12:36 -0800
Re: Getting started with AVR and C Stephen Sprunk <stephen@sprunk.org> - 2012-11-29 16:22 -0600
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 18:36 -0800
Re: Getting started with AVR and C "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2012-12-11 10:53 +0100
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-12-11 14:53 +0000
Unicode Ivan Shmakov <oneingray@gmail.com> - 2012-12-14 23:25 +0700
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-15 14:30 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-15 12:24 -0800
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-15 18:02 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-15 15:45 -0800
Re: Getting started with AVR and C Richard Damon <news.x.richarddamon@xoxy.net> - 2012-12-16 22:55 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-12-16 23:20 -0800
Re: Getting started with AVR and C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:27 +0200
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-12-17 11:17 +0000
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-17 14:07 +0000
Re: Getting started with AVR and C Nobody <nobody@nowhere.com> - 2012-12-16 03:28 +0000
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-12-16 10:40 +0200
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 02:31 +0000
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 03:36 +0000
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 03:55 +0000
Re: Getting started with AVR and C Christopher Head <chead@is.invalid> - 2012-11-28 23:24 -0800
Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 09:37 +0100
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 11:31 +0000
Re: Getting started with AVR and C David Brown <david@westcontrol.removethisbit.com> - 2012-11-29 13:44 +0100
Re: Getting started with AVR and C Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-11-29 13:22 +0100
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 13:32 +0000
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 11:28 -0800
Re: Getting started with AVR and C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-29 13:20 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 09:07 -0500
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 09:17 -0500
Re: Getting started with AVR and C pete <pfiland@mindspring.com> - 2012-11-29 18:25 -0500
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 22:46 -0500
Re: Getting started with AVR and C lawrence.jones@siemens.com - 2012-11-30 11:47 -0500
Re: Getting started with AVR and C Keith Thompson <kst-u@mib.org> - 2012-11-29 11:38 -0800
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 15:21 -0500
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-28 22:26 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 17:32 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 19:02 -0500
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 18:29 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 23:39 -0500
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.please> - 2012-11-29 00:59 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 07:57 -0500
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-29 13:02 -0600
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:19 +0000
Re: Getting started with AVR and C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-11-29 12:03 +0200
Re: Getting started with AVR and C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-29 11:39 +0000
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-29 08:04 -0500
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:17 +0000
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 19:19 -0600
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 23:44 -0500
Re: Getting started with AVR and C James Kuyper <jameskuyper@verizon.net> - 2012-11-28 13:15 -0500
Re: Getting started with AVR and C Arlet Ottens <usenet+5@c-scape.nl> - 2012-11-28 19:17 +0100
Re: Getting started with AVR and C Tim Wescott <tim@seemywebsite.com> - 2012-11-28 19:30 -0600
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 15:29 +0000
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-11-29 16:36 +0000
Re: Getting started with AVR and C upsidedown@downunder.com - 2012-11-29 22:40 +0200
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 13:55 -0800
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 22:06 +0000
Re: Getting started with AVR and C Jon Kirwan <jonk@infinitefactors.org> - 2012-11-29 14:22 -0800
Re: Getting started with AVR and C Grant Edwards <invalid@invalid.invalid> - 2012-11-29 21:59 +0000
Re: Getting started with AVR and C John Devereux <john@devereux.me.uk> - 2012-11-30 08:29 +0000
Re: Getting started with AVR and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-25 05:41 -0800
Re: Getting started with AVR and C Rosario1903 <Rosario@invalid.invalid> - 2012-11-27 10:21 +0100
Re: Getting started with AVR and C dbr@kbrx.com - 2012-11-24 21:49 +0000
Re: Getting started with AVR and C MK <mk@nospam.co.uk> - 2012-11-25 12:24 +0000
Re: Getting started with AVR and C Ian Malcolm <See.My.Sig.for.email@totally.invalid> - 2012-11-26 00:08 +0000
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | John Devereux <john@devereux.me.uk> |
|---|---|
| Date | 2012-12-17 11:17 +0000 |
| Message-ID | <87y5gxdj2l.fsf@devereux.me.uk> |
| In reply to | #10824 |
Keith Thompson <kst-u@mib.org> writes: > Richard Damon <news.x.richarddamon@xoxy.net> writes: >> On 12/11/12 9:53 AM, John Devereux wrote: >>> UTF-8 is the way forward isn't it? >> >> As with most compression systems it depends on what the usage pattern of >> characters is. If the text base is mostly the 7 bit ASCII character set, >> with some of the other lower valued characters and only a few bigger >> valued characters, UTF-8 makes sense. If most of the characters are in >> the larger values (like using a non-Latin based character set) then >> UTF-16 may make much more sense. > > UTF-8 has a couple of other advantages. It's equivalent to ASCII > as long as all the characters are <= 127, which means you can > (mostly) deal with UTF-8 using old tools that aren't Unicode-aware. > And it has no byte ordering issues, so it doesn't need a BOM (Byte > Order Mark). Yes precisely. I had to update an embedded system with a simple home-made gui, so that it could do Chinese. I was pleasantly suprised how painless it was using UTF8. Strings are still null terminated char arrays, most everything just worked as before. You can't predict the number of characters just from the string size, but I was already using proportional fonts so this was not an issue. I could even abuse the C standard - sorry c.l.c - and embed utf8 in the C source code and that worked too. (I moved these out into resource files in the end though). > As for compression, you can always use another compression tool > if necessary; gzipped UTF-8 should be about as compact as gzipped > UTF-16. -- John Devereux
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-12-17 14:07 +0000 |
| Message-ID | <0.5ce56e2f35a5807d5e74.20121217140745GMT.874njkdb66.fsf@bsb.me.uk> |
| In reply to | #10838 |
John Devereux <john@devereux.me.uk> writes: <snip> > [...] I could even abuse the C > standard - sorry c.l.c - and embed utf8 in the C source code and that > worked too. (I moved these out into resource files in the end though). It's not much of an abuse. Multibyte character sequences are permitted in string literals and may even be converted to wide character strings as if by the use of the mbstowcs function when appropriate. In C99, the only trouble is that what encoding is assumed, and what characters are permitted, is implementation defined. Whilst that's also true in the latest standard, C11 does add the u8 prefix to produce UTF-8 encoded strings. It also adds the U (and u) prefix to make Unicode character arrays from a multibyte character string, but the encoding is still implementation defined and dependent on the locale (as it should be, I think). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2012-12-16 03:28 +0000 |
| Message-ID | <pan.2012.12.16.03.28.56.823000@nowhere.com> |
| In reply to | #10823 |
On Sat, 15 Dec 2012 14:30:44 -0500, Richard Damon wrote:
>> UTF-8 is the way forward isn't it?
>>
>
> As with most compression systems it depends on what the usage pattern of
> characters is. If the text base is mostly the 7 bit ASCII character set,
> with some of the other lower valued characters and only a few bigger
> valued characters, UTF-8 makes sense. If most of the characters are in
> the larger values (like using a non-Latin based character set) then
> UTF-16 may make much more sense.
Size isn't the only issue; the fact that UTF-16 may (and usually does)
contain null bytes ('\0') rules it out for many applications.
Similarly, anything which expects specific bytes (e.g. '\x0a', '\x0d',
etc) to have their "usual" meanings regardless of context will work fine
with UTF-8 but not with UTF-16 or UTF-32.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2012-12-16 10:40 +0200 |
| Message-ID | <in0rc8l4qqcmk3viffh5458qklsqduo4vi@4ax.com> |
| In reply to | #10823 |
On Sat, 15 Dec 2012 14:30:44 -0500, Richard Damon <news.x.richarddamon@xoxy.net> wrote: >On 12/11/12 9:53 AM, John Devereux wrote: >> >> UTF-8 is the way forward isn't it? >> > >As with most compression systems it depends on what the usage pattern of >characters is. If the text base is mostly the 7 bit ASCII character set, >with some of the other lower valued characters and only a few bigger >valued characters, UTF-8 makes sense. If most of the characters are in >the larger values (like using a non-Latin based character set) then >UTF-16 may make much more sense. For any given non-Latin based language, there are only a few possible bit combinations in the first byte(s) of the UTF-8 sequence, thus it should compress quite well. For use inside a program, UTF-32 would be the natural choice with 1 array element/character. Compressing a UTF-32 file using some form of Huffman coding, should not take more space than compressed UTF-8/UTF-16 files, since the actually used (and stored) symbol table would reflect the actual usage of sequences in the whole file. Doing the compression on the fly in a communication link would be less effective, since only a part of the data would be available at a time, in order to keep the latencies acceptable.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-29 02:31 +0000 |
| Message-ID | <k96he8$m87$1@speranza.aioe.org> |
| In reply to | #10611 |
In comp.lang.c David Brown <david.brown@removethis.hesbynett.no> wrote: (snip, someone wrote) >>> I would expect that gcc would be ANSI compliant, and would therefore >>> promote both 16-bit integers to 32-bit before doing the multiply. (snip, then I wrote) >> Maybe I am missing something here, but are there versions of gcc for 16 >> bit processors, with 16 bit int? If so, then promotion to int won't >> promote to 32 bits without a cast. > The correct behaviour for C standards compliance is that when you > multiply two operands of different int size, the smaller one is promoted > to the size of the larger one. Then the multiply is carried out modulo > the size of the larger one. Then the result is truncated or extended as > needed to fit the target variable. I haven't read the standard so recently, but I thought that was only after the default promotions. Values smaller than int would be promoted to int, then the size of the multiply (and product) determined. If you multiply two 8 bit unsigned char values, is the product modulo 256? I don't think so. > So the bit-size of the processor, and the bit-size of "int" on that > particular target, is irrelevant. And the size of the result variable > is also irrelevant (this catches out some newbies). > Given: > int16_t a, b; > int32_t c > c = (int32_t)a * b; > Then b is cast to int32_t, the 32-bit multiplication is carried out, and > the result assigned to c. Maybe not completely irrelevent, consider a system with a 64 bit int. > If you write just "c = a * b", then the multiplication is carried it at > 16-bit, then promoted to 32-bit. This applies regardless of the > bit-size of the target - you will get the same effect on a 64-bit cpu as > on the 8-bit AVR. Regardless of the target size, but not of int size. > If your compiler does 16-bit multiplications when you have "c = > (int32_t) a * b", and requires two "int32_t" casts to do 32-bit > multiplication, then your compiler is very badly broken. As Tim says, > badly broken compilers /do/ exist, so if you have to use them, then you > need to use two casts. But I personally don't think you need to write > your code to work with broken toolchains unless you actually have to. Now it gets interesting. When were the int_32_t and int_16_t added to C? Seems to me that compilers only claiming a version of the standard before they were added wouldn't have to use the same rules. Consider that a compiler might have a int_128_t that it could add and subtract, but not multiply or divide. Maybe it can generate a 128 bit product from two 64 bit operands. Does the standard prohibit a compiler from offering those operations? -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-29 03:36 +0000 |
| Message-ID | <0.b5bb6f0bd3131aed6a68.20121129033612GMT.87txs9rsgj.fsf@bsb.me.uk> |
| In reply to | #10617 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > In comp.lang.c David Brown <david.brown@removethis.hesbynett.no> wrote: > > (snip, someone wrote) >>>> I would expect that gcc would be ANSI compliant, and would therefore >>>> promote both 16-bit integers to 32-bit before doing the multiply. > > (snip, then I wrote) >>> Maybe I am missing something here, but are there versions of gcc for 16 >>> bit processors, with 16 bit int? If so, then promotion to int won't >>> promote to 32 bits without a cast. > >> The correct behaviour for C standards compliance is that when you >> multiply two operands of different int size, the smaller one is promoted >> to the size of the larger one. Then the multiply is carried out modulo >> the size of the larger one. Then the result is truncated or extended as >> needed to fit the target variable. > > I haven't read the standard so recently, but I thought that was only > after the default promotions. Values smaller than int would be promoted > to int, then the size of the multiply (and product) determined. Yes, it's two-stage process. In case it helps, here is the terminology as used by the C standard: "integer promotions" These are the conversions that often occur prior to preforming an arithmetic operation. They form part of the: "usual arithmetic conversions" which is how a common type is arrived at for arithmetic operations that requite it. Unless complex or floating types are involved, the integer promotions are performed on both operands and then a set of rules is used to determine the common type. For integer types it is usually simply the widest of the two, even if that is an unsigned type and the other is a signed type. "default argument promotions" apply to function calls in the absence of a prototype. These are the integer promotions augmented by a conversion of float to double. The standard never refers to a conversion as a cast (a cast is an operator that performs an explicit conversion) and it uses the term "promotion" only in the context of the implicit conversions described above. A conversion of one type to a wider one in some other context is not called a promotion. > If you multiply two 8 bit unsigned char values, is the product > modulo 256? I don't think so. No, it's not. <snip> > Now it gets interesting. When were the int_32_t and int_16_t added to > C? 1999. The types are intN_t and uintN_t (no extra _) for various N. They are optional, but must be defined if the implementation has suitable types (basically 2's complement and no padding bits). Other, similar, types like int_leastN_t and int_fastN_t are required in all implementations. For example, int_least32_t is the smallest type that has at least 32 (value) bits. > Seems to me that compilers only claiming a version of the standard > before they were added wouldn't have to use the same rules. True. > Consider that a compiler might have a int_128_t that it could add and > subtract, but not multiply or divide. Maybe it can generate a 128 bit > product from two 64 bit operands. Does the standard prohibit a > compiler from offering those operations? I don't think it could define int128_t unless it could multiply them. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-29 03:55 +0000 |
| Message-ID | <k96mbu$vm2$1@speranza.aioe.org> |
| In reply to | #10618 |
In comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: (snip, I wrote) >> If you multiply two 8 bit unsigned char values, is the product >> modulo 256? I don't think so. > No, it's not. For comparison purposes, I believe that Fortran does not have this rule. If you add, subtract, multiply, or (I believe) divide 8 bit integers the result is, generally, eight bits. One should, at least, not be surprised if the result is computed modulo some small value. I like the C rules better. PL/I generally tries to keep the bits until it reaches the implementation maximum. That is complicated when scaled fixed point (non-integer) values are used, where it keeps the appropriate digits (binary or decimal) to the right of the radix point, possibly truncating on the left. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Christopher Head <chead@is.invalid> |
|---|---|
| Date | 2012-11-28 23:24 -0800 |
| Message-ID | <20121128232405.040da567@kruskal.chead> |
| In reply to | #10619 |
On Thu, 29 Nov 2012 03:55:43 +0000 (UTC) glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > In comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > > (snip, I wrote) > > >> If you multiply two 8 bit unsigned char values, is the product > >> modulo 256? I don't think so. > > > No, it's not. > > For comparison purposes, I believe that Fortran does not have this > rule. > > If you add, subtract, multiply, or (I believe) divide 8 bit integers > the result is, generally, eight bits. One should, at least, not be > surprised if the result is computed modulo some small value. > > I like the C rules better. > > PL/I generally tries to keep the bits until it reaches the > implementation maximum. That is complicated when scaled fixed > point (non-integer) values are used, where it keeps the appropriate > digits (binary or decimal) to the right of the radix point, > possibly truncating on the left. Remember the "as if" clause. In reality, if you add, subtract, multiply, or divide two uint8_ts and store the result in another uint8_t on a CPU where 8-bit arithmetic operations are faster than larger operations (or do the same with at least some of those operations for signed numbers which happen, implementation-specifically, to be implemented in twos-complement), any sane compiler *will* perform the operations at 8-bit width because the results in all cases are provably equivalent to the same operations performed with promotion. Chris
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-11-29 09:37 +0100 |
| Message-ID | <OdWdnXwRtuUQvSrNnZ2dnUVZ8uSdnZ2d@lyse.net> |
| In reply to | #10617 |
On 29/11/2012 03:31, glen herrmannsfeldt wrote: > In comp.lang.c David Brown <david.brown@removethis.hesbynett.no> wrote: > > (snip, someone wrote) >>>> I would expect that gcc would be ANSI compliant, and would therefore >>>> promote both 16-bit integers to 32-bit before doing the multiply. > > (snip, then I wrote) >>> Maybe I am missing something here, but are there versions of gcc for 16 >>> bit processors, with 16 bit int? If so, then promotion to int won't >>> promote to 32 bits without a cast. > >> The correct behaviour for C standards compliance is that when you >> multiply two operands of different int size, the smaller one is promoted >> to the size of the larger one. Then the multiply is carried out modulo >> the size of the larger one. Then the result is truncated or extended as >> needed to fit the target variable. > > I haven't read the standard so recently, but I thought that was only > after the default promotions. Values smaller than int would be promoted > to int, then the size of the multiply (and product) determined. As pointed out by Hans-Bernhard, you are correct here. I'm sorry for causing confusion by posting while half asleep. Default "int" promotions are done first for each operand. They are promoted to "signed int", "unsigned int", "signed long int" or "unsigned long int" (and "long long" for newer C standards), stopping at the first type that covers the entire range. In practice, this means anything smaller than an "int" will get promoted to a "signed int". > > If you multiply two 8 bit unsigned char values, is the product > modulo 256? I don't think so. > >> So the bit-size of the processor, and the bit-size of "int" on that >> particular target, is irrelevant. And the size of the result variable >> is also irrelevant (this catches out some newbies). > >> Given: > >> int16_t a, b; >> int32_t c > >> c = (int32_t)a * b; > >> Then b is cast to int32_t, the 32-bit multiplication is carried out, and >> the result assigned to c. > > Maybe not completely irrelevent, consider a system with a 64 bit int. > >> If you write just "c = a * b", then the multiplication is carried it at >> 16-bit, then promoted to 32-bit. This applies regardless of the >> bit-size of the target - you will get the same effect on a 64-bit cpu as >> on the 8-bit AVR. > > Regardless of the target size, but not of int size. > >> If your compiler does 16-bit multiplications when you have "c = >> (int32_t) a * b", and requires two "int32_t" casts to do 32-bit >> multiplication, then your compiler is very badly broken. As Tim says, >> badly broken compilers /do/ exist, so if you have to use them, then you >> need to use two casts. But I personally don't think you need to write >> your code to work with broken toolchains unless you actually have to. > > Now it gets interesting. When were the int_32_t and int_16_t added to C? > The types were officially added with C99, but they existed in practice before that as "long int" and "short int" on most compilers (some targets don't support 16-bit types, and thus have "short int" as 32-bit and no int16_t. And the standards allow compilers with a "short" of 64-bit or more, in which case neither "int32_t" nor "int16_t" would exist - but I have never heard of such a beast). > Seems to me that compilers only claiming a version of the standard > before they were added wouldn't have to use the same rules. The rules haven't changed (again, sorry for my mistaken post). Types such as "int32_t" are just typedef's for "normal" C types. > > Consider that a compiler might have a int_128_t that it could add and > subtract, but not multiply or divide. Maybe it can generate a 128 bit > product from two 64 bit operands. Does the standard prohibit a > compiler from offering those operations? > The "int128_t" here is either a typedef for an existing C type (which could include "long long int" in C99), in which case it would have to support all integral operations, or it is purely a compiler extension, in which case it is non-standard. But I believe the standards say that /if/ a type of this form "int128_t" is defined in standard headers for the compiler, then it must act as a full integral type of that size.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-29 11:31 +0000 |
| Message-ID | <k97h2p$qem$1@speranza.aioe.org> |
| In reply to | #10625 |
In comp.lang.c David Brown <david@westcontrol.removethisbit.com> wrote: (snip) >> Now it gets interesting. When were the int_32_t and int_16_t added to C? > The types were officially added with C99, but they existed in practice > before that as "long int" and "short int" on most compilers (some > targets don't support 16-bit types, and thus have "short int" as 32-bit > and no int16_t. And the standards allow compilers with a "short" of > 64-bit or more, in which case neither "int32_t" nor "int16_t" would > exist - but I have never heard of such a beast). >> Seems to me that compilers only claiming a version of the standard >> before they were added wouldn't have to use the same rules. > The rules haven't changed (again, sorry for my mistaken post). Types > such as "int32_t" are just typedef's for "normal" C types. Most likely, but as they aren't in the C89 standard, unless the user typedef's them, seems to me the compiler is free to implement then in any way desired. -- glen
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-11-29 13:44 +0100 |
| Message-ID | <JPWdndqP6p7AxyrNnZ2dnUVZ8hidnZ2d@lyse.net> |
| In reply to | #10627 |
On 29/11/2012 12:31, glen herrmannsfeldt wrote: > In comp.lang.c David Brown <david@westcontrol.removethisbit.com> wrote: > > (snip) >>> Now it gets interesting. When were the int_32_t and int_16_t added to C? > >> The types were officially added with C99, but they existed in practice >> before that as "long int" and "short int" on most compilers (some >> targets don't support 16-bit types, and thus have "short int" as 32-bit >> and no int16_t. And the standards allow compilers with a "short" of >> 64-bit or more, in which case neither "int32_t" nor "int16_t" would >> exist - but I have never heard of such a beast). > >>> Seems to me that compilers only claiming a version of the standard >>> before they were added wouldn't have to use the same rules. > >> The rules haven't changed (again, sorry for my mistaken post). Types >> such as "int32_t" are just typedef's for "normal" C types. > > Most likely, but as they aren't in the C89 standard, unless the > user typedef's them, seems to me the compiler is free to implement > then in any way desired. > That is correct - but I would be very surprised to see a compiler that did have a type with a name like that, and did not implement it the obvious way. It might be /legal/ under C89 rules for the compiler to have a type called "int32_t" with different behaviour, but I can't imagine it actually being the case. I'm sure Tim Wescott can think of an exception, however!
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2012-11-29 13:22 +0100 |
| Message-ID | <ahp2crFk8jeU1@mid.dfncis.de> |
| In reply to | #10625 |
On 29.11.2012 09:37, David Brown wrote:
> On 29/11/2012 03:31, glen herrmannsfeldt wrote:
>> Consider that a compiler might have a int_128_t that it could add and
>> subtract, but not multiply or divide. Maybe it can generate a 128 bit
>> product from two 64 bit operands. Does the standard prohibit a
>> compiler from offering those operations?
> The "int128_t" here is either a typedef for an existing C type (which
> could include "long long int" in C99), in which case it would have to
> support all integral operations, or it is purely a compiler extension,
> in which case it is non-standard.
Since we were nit-picking anyway: not quite. As of C99 the standard
explicitly foresees the possible need to have more than the usual 10
different integer types ({signed|unsigned} {char|short|int|long|long
long}) in a target. That's why they included a provision for "extended
integer types". These types don't have standardized names (because they
can't), but their behaviour is still covered by the standard.
So the type behind int128_t need not be an "existing C type" (as in:
something that was already defined before), nor is it allowed to be a
pure compiler extension (which the standard would have no say over at
all). If it's an extension, it has to be a standard extension, so its
behaviour is ruled by the standard.
> But I believe the standards say that
> /if/ a type of this form "int128_t" is defined in standard headers for
> the compiler, then it must act as a full integral type of that size.
Yes.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-29 13:32 +0000 |
| Message-ID | <0.43ed7817676c52e3713f.20121129133210GMT.87ip8osffp.fsf@bsb.me.uk> |
| In reply to | #10629 |
Hans-Bernhard Bröker <HBBroeker@t-online.de> writes:
<snip>
> Since we were nit-picking anyway: not quite. As of C99 the standard
> explicitly foresees the possible need to have more than the usual 10
> different integer types ({signed|unsigned} {char|short|int|long|long
> long}) in a target.
These may be the usual ones, but there are 11 "standard integer types"
because they include _Bool. (Well, you did say we are nit-picking!)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-29 11:28 -0800 |
| Message-ID | <ln624ob44z.fsf@nuthaus.mib.org> |
| In reply to | #10634 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Hans-Bernhard Bröker <HBBroeker@t-online.de> writes:
> <snip>
>> Since we were nit-picking anyway: not quite. As of C99 the standard
>> explicitly foresees the possible need to have more than the usual 10
>> different integer types ({signed|unsigned} {char|short|int|long|long
>> long}) in a target.
>
> These may be the usual ones, but there are 11 "standard integer types"
> because they include _Bool. (Well, you did say we are nit-picking!)
And plain char *isn't* one of the "standard integer types", even
though it's a standard type, and it's an integer type, and its
characteristics (range, representation, and behavior) are identical
either to those of signed char or to those of unsigned char, both
of which are "standard integer types".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-29 13:20 +0000 |
| Message-ID | <0.9ce9ce1f7e5910c691fa.20121129132009GMT.87obigsfzq.fsf@bsb.me.uk> |
| In reply to | #10625 |
David Brown <david@westcontrol.removethisbit.com> writes: > On 29/11/2012 03:31, glen herrmannsfeldt wrote: >> In comp.lang.c David Brown <david.brown@removethis.hesbynett.no> wrote: >> >> (snip, someone wrote) >>>>> I would expect that gcc would be ANSI compliant, and would therefore >>>>> promote both 16-bit integers to 32-bit before doing the multiply. >> >> (snip, then I wrote) >>>> Maybe I am missing something here, but are there versions of gcc for 16 >>>> bit processors, with 16 bit int? If so, then promotion to int won't >>>> promote to 32 bits without a cast. >> >>> The correct behaviour for C standards compliance is that when you >>> multiply two operands of different int size, the smaller one is promoted >>> to the size of the larger one. Then the multiply is carried out modulo >>> the size of the larger one. Then the result is truncated or extended as >>> needed to fit the target variable. >> >> I haven't read the standard so recently, but I thought that was only >> after the default promotions. Values smaller than int would be promoted >> to int, then the size of the multiply (and product) determined. > > As pointed out by Hans-Bernhard, you are correct here. I'm sorry for > causing confusion by posting while half asleep. > > Default "int" promotions are done first for each operand. They are > promoted to "signed int", "unsigned int", "signed long int" or > "unsigned long int" (and "long long" for newer C standards), stopping > at the first type that covers the entire range. In practice, this > means anything smaller than an "int" will get promoted to a "signed > int". That's not quite right, though I'm not exactly sure what you mean. As you say, the integer promotions are done first. That can produce either an int or an unsigned int, or it may have no effect at all if the type is already "bigger" than an int. Then one operand, but sometimes both operands, are further converted (not promoted) to get a common type. You can read the rules at www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (sec. 6.3.1.8) but the conversion does not stop at the first type that covers the entire range (at least according to how I interpret that phrase). For example, in (unsigned)1 * (signed)-1 the signed operand is converted to the type of the unsigned one even though that type can't cover the entire range of the operand or operands. Almost any summary of the rules is going to be wrong; if an accurate summary can be written it should go into the language standard -- it would be a great boon -- but I don't think that's possible. For example I had to put "bigger" in quotes because the rule is based on a technical term called the conversion rank of the type and not on its size. (The integer promotions have no effect on a long int even on systems where a long int is no bigger than an int). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-29 09:07 -0500 |
| Message-ID | <k97q71$hn3$1@dont-email.me> |
| In reply to | #10625 |
On 11/29/2012 03:37 AM, David Brown wrote: ... > Default "int" promotions are done first for each operand. They are > promoted to "signed int", "unsigned int", "signed long int" or "unsigned > long int" (and "long long" for newer C standards), stopping at the first > type that covers the entire range. In practice, this means anything > smaller than an "int" will get promoted to a "signed int". Not quite. The integer conversions never change anything to any type other than 'int' or 'unsigned int'. "If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions.58) All other types are unchanged by the integer promotions." (6.3.1.1p2) The first use of "integer promotions" in that clause is italicized, which is an ISO convention indicating that the sentence containing that phrase serves as the definition of the phrase. .. >> Now it gets interesting. When were the int_32_t and int_16_t added to C? >> > > The types were officially added with C99, but they existed in practice > before that as "long int" and "short int" on most compilers (some > targets don't support 16-bit types, and thus have "short int" as 32-bit > and no int16_t. And the standards allow compilers with a "short" of > 64-bit or more, in which case neither "int32_t" nor "int16_t" would > exist - but I have never heard of such a beast). I've heard of machines with 32-bit short, but not 64-bit. Note that while int32_t and int16_t could not be provided by <stdint.h> for such a compiler, int_least32_t and int_fast32_t (and similarly for 16) must be. >> Seems to me that compilers only claiming a version of the standard >> before they were added wouldn't have to use the same rules. > > The rules haven't changed (again, sorry for my mistaken post). ... Yes they have. In C99 and later, <stdint.h> and <inttypes.h> are standard headers, and if #included, the identifiers they define must meet certain well-specified requirements. In C90, there were no such standard headers, no guarantees on what a header file with that name would contain if you successfully #included it, and no corresponding restrictions on how user code could use those identifiers after #including those header files. > ... Types > such as "int32_t" are just typedef's for "normal" C types. That depends upon what you mean by 'normal'. The C99 standard distinguishes between standard and extended integer types. The standard integer types have names specified by the C standard; extended types are implementation-defined, and may have other names. There are many standard typedefs that are required to have either arithmetic or integer type; but there are none that are restricted to standard integer types. Would you consider __extended_integer_type to be a "normal" C type? ... > The "int128_t" here is either a typedef for an existing C type (which > could include "long long int" in C99), in which case it would have to > support all integral operations, or it is purely a compiler extension, > in which case it is non-standard. No, supporting int128_t would not be a non-standard extension, it's just providing an optional feature of standard C. The key difference is that if an implementation chooses to support an optional feature, it must support it in precisely the manner specified by the standard for that feature; extensions give an implementation a lot more freedom. In C2011, there's a lot of optional features. The only size-named types that a conforming implementation of <stdint.h> must provide are [u]int_leastN_t, and [u]int_fastN_t for N = 8, 16, 32, and 64. For all other values of N, and for [u]intN_t for all values of N, the typedefs are optional. You can determine precisely which of the optional <stdint.h> types are supported by #ifdef of the corresponding *_MAX macro. If that macro is #defined, you can use the corresponding type in full confidence that it behaves precisely as specified by the standard. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-29 09:17 -0500 |
| Message-ID | <k97qpg$lci$1@dont-email.me> |
| In reply to | #10635 |
On 11/29/2012 09:07 AM, James Kuyper wrote: ... > "If an int can represent all values of the original type (as restricted > by the width, for a bit-field), the value is converted to an int; > otherwise, it is converted to an unsigned int. These are called the > integer promotions.58) All other types are unchanged by the integer > promotions." (6.3.1.1p2) The first use of "integer promotions" in that > clause is italicized, which is an ISO convention indicating that the > sentence containing that phrase serves as the definition of the phrase. I just realized that the meaning of the phrase "All other types" is not clear without the preceding part of that clause which I snipped: > The following may be used in an expression wherever an int or unsigned int may > be used: > — An object or expression with an integer type (other than int or unsigned int) > whose integer conversion rank is less than or equal to the rank of int and > unsigned int. > — A bit-field of type _Bool, int, signed int, or unsigned int. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2012-11-29 18:25 -0500 |
| Message-ID | <50B7EEF8.29B9@mindspring.com> |
| In reply to | #10636 |
James Kuyper wrote: > > On 11/29/2012 09:07 AM, James Kuyper wrote: > ... > > "If an int can represent all values of the original type > > (as restricted > > by the width, for a bit-field), the value is converted to an int; > > otherwise, it is converted to an unsigned int. These are called the > > integer promotions.58) All other types are unchanged by the integer > > promotions." > > (6.3.1.1p2) The first use of "integer promotions" in that > > clause is italicized, which is an ISO convention indicating > > that the > > sentence containing that phrase serves > > as the definition of the phrase. > > I just realized that the meaning of the phrase "All other types" > is not > clear without the preceding part of that clause which I snipped: > > > The following may be used in an expression > > wherever an int or unsigned int may > > be used: > > — An object or expression with an integer type > > (other than int or unsigned int) > > whose integer conversion rank is less than > > or equal to the rank of int and unsigned int. > > — > > A bit-field of type _Bool, int, signed int, or unsigned int. I recall reading some posts in this newsgroup a long time ago, which claimed that under certain circumstances, that it was possible in C99, for unsigned int to promote to type signed int. But that was never the case. In C99 6.3.1.1 paragraph 2, read as "less than" instead of "less than or equal" as you have above; and unsigned int type was covered by "All other types" in the last sentence. -- pete
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-29 22:46 -0500 |
| Message-ID | <k99a7e$cr2$1@dont-email.me> |
| In reply to | #10659 |
On 11/29/2012 06:25 PM, pete wrote: > James Kuyper wrote: >> >> On 11/29/2012 09:07 AM, James Kuyper wrote: >> ... >>> "If an int can represent all values of the original type >>> (as restricted >>> by the width, for a bit-field), the value is converted to an int; >>> otherwise, it is converted to an unsigned int. These are called the >>> integer promotions.58) All other types are unchanged by the integer >>> promotions." >>> (6.3.1.1p2) The first use of "integer promotions" in that >>> clause is italicized, which is an ISO convention indicating >>> that the >>> sentence containing that phrase serves >>> as the definition of the phrase. >> >> I just realized that the meaning of the phrase "All other types" >> is not >> clear without the preceding part of that clause which I snipped: >> >>> The following may be used in an expression >>> wherever an int or unsigned int may >>> be used: >>> — An object or expression with an integer type >>> (other than int or unsigned int) >>> whose integer conversion rank is less than >>> or equal to the rank of int and unsigned int. >>> — >>> A bit-field of type _Bool, int, signed int, or unsigned int. > > I recall reading some posts in this newsgroup a long time ago, > which claimed that under certain circumstances, > that it was possible in C99, > for unsigned int to promote to type signed int. An unsigned type whose entire range can be represented by an int will promote to signed int, as can easily be confirmed by checking the above text, and that point has been raised in this group - there were several threads that touched on that subject in just this past summer. However, anyone who claimed that it could happen to "unsigned int" was mistaken. That clause explicitly applies only to types "other than int or unsigned int". > But that was never the case. > > In C99 > 6.3.1.1 paragraph 2, read as "less than" > instead of "less than or equal" as you have above; > and unsigned int type was covered by "All other types" > in the last sentence. n1256.pdf (which is C99 with all three TCs applied, making it MORE useful than C99 itself) and n1570.pdf (which is essentially identical to C2011) both have "less than or equal to". The line is marked as being changed from C99 in n1256.pdf, implying that one of the TCs is the reason. My copy of C99 itself is inaccessible right now, so I can't confirm the nature of the change. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | lawrence.jones@siemens.com |
|---|---|
| Date | 2012-11-30 11:47 -0500 |
| Message-ID | <oi4no9-4gh.ln1@jones.homeip.net> |
| In reply to | #10662 |
James Kuyper <jameskuyper@verizon.net> wrote: > > n1256.pdf (which is C99 with all three TCs applied, making it MORE > useful than C99 itself) and n1570.pdf (which is essentially identical to > C2011) both have "less than or equal to". The line is marked as being > changed from C99 in n1256.pdf, implying that one of the TCs is the > reason. My copy of C99 itself is inaccessible right now, so I can't > confirm the nature of the change. It was TC2 and the change came from DR 230. It was to handle the case of enumerationed types with the same rank as int, it didn't have anything to do with unsigned int. -- Larry Jones I'm a genius. -- Calvin
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web