Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167553 > unrolled thread
| Started by | ManyBeers <markzuffi@yahoo.com> |
|---|---|
| First post | 2022-09-08 11:34 -0700 |
| Last post | 2022-09-13 15:44 -0700 |
| Articles | 20 on this page of 95 — 15 participants |
Back to article view | Back to comp.lang.c
Beginner....Decimal/Octal converter help ManyBeers <markzuffi@yahoo.com> - 2022-09-08 11:34 -0700
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-08 11:56 -0700
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-08 20:19 +0100
Re: Beginner....Decimal/Octal converter help Barry Schwarz <schwarzb@delq.com> - 2022-09-08 12:34 -0700
Re: Beginner....Decimal/Octal converter help Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2022-09-08 20:38 -0600
Re: Beginner....Decimal/Octal converter help Öö Tiib <ootiib@hot.ee> - 2022-09-09 03:22 -0700
Re: Beginner....Decimal/Octal converter help gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-09 13:30 +0000
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-09 09:16 -0700
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-09 19:06 +0000
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-10 11:58 +0200
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-10 11:37 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-10 13:05 +0200
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-10 14:42 +0000
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-10 16:10 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-10 18:14 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-10 12:54 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-10 16:22 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-10 19:03 +0100
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-10 19:30 +0100
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-10 19:47 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-11 14:07 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-11 16:12 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-11 17:58 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-11 21:14 +0100
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 20:01 -0700
Re: Beginner....Decimal/Octal converter help Richard Damon <Richard@Damon-Family.org> - 2022-09-11 23:32 -0400
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 13:52 +0000
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 03:24 -0700
Re: Beginner....Decimal/Octal converter help Richard Damon <Richard@Damon-Family.org> - 2022-09-14 08:10 -0400
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-26 06:09 -0800
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-12 16:53 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 16:48 +0100
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-12 17:46 +0100
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 20:37 +0100
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-13 00:03 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-13 12:31 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-13 12:48 +0100
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-13 14:18 +0100
Re: Beginner....Decimal/Octal converter help Anton Shepelev <anton.txt@g{oogle}mail.com> - 2022-09-13 17:13 +0300
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-13 16:50 +0100
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-13 18:47 +0100
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-14 03:16 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-13 20:15 +0200
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-13 20:29 +0000
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-13 22:22 +0100
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-13 14:37 -0700
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-13 23:16 +0100
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-13 22:16 +0000
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-13 16:15 -0700
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-13 16:15 -0700
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-14 10:58 +0100
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-14 15:36 +0100
Re: Beginner....Decimal/Octal converter help Richard Harnden <richard.nospam@gmail.com> - 2022-09-14 21:53 +0100
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-14 05:55 +0000
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-14 10:10 +0200
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-14 07:54 -0700
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-14 18:32 +0200
Re: Beginner....Decimal/Octal converter help Bart <bc@freeuk.com> - 2022-09-14 18:39 +0100
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-15 01:12 +0000
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-15 09:11 +0200
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-15 08:07 -0700
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-14 18:40 +0000
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-14 05:45 +0000
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-14 12:11 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-14 09:57 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-14 03:09 +0100
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-14 10:29 +0200
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-14 15:14 +0100
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 07:36 -0700
Re: Beginner....Decimal/Octal converter help Öö Tiib <ootiib@hot.ee> - 2022-10-03 01:10 -0700
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-03 11:36 +0100
Re: Beginner....Decimal/Octal converter help Öö Tiib <ootiib@hot.ee> - 2022-10-04 02:13 -0700
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-04 16:27 +0100
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-13 11:48 -0700
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-14 10:38 +0200
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-14 14:27 +0000
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-14 07:58 -0700
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-16 13:06 -0700
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-16 13:16 -0700
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 17:55 +0000
Re: Beginner....Decimal/Octal converter help Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-12 18:22 +0000
Re: Beginner....Decimal/Octal converter help Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 20:41 +0100
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-11 15:45 -0700
Re: Beginner....Decimal/Octal converter help Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-11 15:41 -0700
Re: Beginner....Decimal/Octal converter help David Brown <david.brown@hesbynett.no> - 2022-09-12 17:06 +0200
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 06:46 -0700
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 06:57 -0700
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 07:07 -0700
Neologism (Was: Beginner....Decimal/Octal converter help) gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-11 14:18 +0000
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-11 16:33 +0000
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 15:40 -0700
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-09 23:08 +0000
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 06:37 -0700
Re: Beginner....Decimal/Octal converter help scott@slp53.sl.home (Scott Lurndal) - 2022-09-11 16:31 +0000
Re: Beginner....Decimal/Octal converter help Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 15:44 -0700
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-15 08:07 -0700 |
| Message-ID | <864jx8n0am.fsf@linuxsc.com> |
| In reply to | #167730 |
Kaz Kylheku <480-992-1380@kylheku.com> writes:
> On 2022-09-14, Bart <bc@freeuk.com> wrote:
>
>> And, because even those int8_t types are so hackish, C already suffers
>> from poor support for those types for:
>
> These hapless {u}int8 types are a pitfall.
>
> In C there are certain requirements that an object may be accessed
> through an lvalue of character type. That's more or less the basis for
> the validity of being able to memcpy an object to a compatible object
> (that topic is a whole can of worms, and I won't comment on it
> further).
>
> I'm getting to the point that these requirements do not extend to the
> "int8" family of types, even if they are de facto the same thing on a
> given imlementation.
>
> If you use uint8_t as a substitute for unsigned char, you could
> be bringing in undefined behavior. It's not worth it;
> just stay away.
My sentiments exactly.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-09-14 18:40 +0000 |
| Message-ID | <20220914111818.546@kylheku.com> |
| In reply to | #167718 |
On 2022-09-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> In the context of other parts of code, it can be obvious that the >> exact size is important - but it is usually only important in terms of >> being a size that is big enough for your needs, and fits the target >> well. That might sound exactly like a description of "uint_fast32_t", >> but it is not. When you write "uint_fast32_t", you are telling the >> reader "this code, and this variable, is speed critical" whether it is >> true or not. It is a bit like declaring the variable "register" - the >> compiler will ignore the hint (unless you try to take the variable's >> address), but it tells human readers that you think the variable is >> critical. > > I think "speed critical" is an overstatement. I'd say that > uint_fast32_t means I need at least 32 bits, and performance is more > important than small size. For example, if 64-bit operations are faster > than 32-bit operations, I'd rather use 64 bits than 32 -- which is almost > certainly the right choice if I'm only defining one object rather than a > large array. > > It's may not have been the best decision to use the shorter names for > the exact types. It absolutely was, for the reason that the decimal integers 8, 16, 32 and 64 do not need to be called "exactly 8", "exactly 16", and so on. In the absence of any qualification, they already denote exact values. Secondly, those types are the ones that are actually used, and play a role in interfacing: ABI definitions, information headers in packets and files, hardware uses. Nobody in their right mind would use those rubbery "least" and "fast" types in an API as a function parameter or structure member. That would have all the problems of using int, short, long, or long long, plus additional uncertainty on top of that. The commonly used thing should have the short name without redundant qualifiers; let the disused articles bear the verbosity.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-09-14 05:45 +0000 |
| Message-ID | <20220913223935.376@kylheku.com> |
| In reply to | #167681 |
On 2022-09-13, Bart <bc@freeuk.com> wrote: > You said you need a field of 30 bits, so how would uint_least32_t be > better than uint_32t? There is the catch. Unless you have reasons to suspect that your program will be ported to a system where there is no uint32_t, then there is no reason to use uint_least32_t. It's "better" in that situation when it's available and uint32_t isn't. Which explains why you you will hardly ever see it being used.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-14 12:11 +0100 |
| Message-ID | <87h71aqkgo.fsf@bsb.me.uk> |
| In reply to | #167695 |
Kaz Kylheku <480-992-1380@kylheku.com> writes: > On 2022-09-13, Bart <bc@freeuk.com> wrote: >> You said you need a field of 30 bits, so how would uint_least32_t be >> better than uint_32t? > > There is the catch. Unless you have reasons to suspect that your program > will be ported to a system where there is no uint32_t, then there > is no reason to use uint_least32_t. > > It's "better" in that situation when it's available and uint32_t > isn't. This all started because I think (u)int_least32_t and (u)uint_fast32_t often better describe what the programmer intends: int_least32_t: "I need at least 32 bits but I'm worried about space" int_fast_32_t: "I need at least 32 bits but I'll take wider if it's faster" int32_t: "I need exactly 32 bits, probably to match something external" With the u versions, the last one (uint32_t) gets a new use: "I need exactly 32 bits, possibly because the algorithm needs mod 2^32 wrapping". > Which explains why you you will hardly ever see it being used. I think there are other explanations. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-14 09:57 +0200 |
| Message-ID | <tfs1i3$2rqt2$1@dont-email.me> |
| In reply to | #167680 |
On 13/09/2022 22:29, Kaz Kylheku wrote: > On 2022-09-13, David Brown <david.brown@hesbynett.no> wrote: >> But I don't think C is that kind of language, and I remain unconvinced >> that heavy use of the "least" and "fast" types is anything more than >> baby steps towards such abstractions. (I am, I think, a little more >> open to their use than I was before this subthread started, however.) > > The "least" business is a straightforward extension of how the ordinary > types are. For instance, long is at least 32 bits wide, short at least > 16 and so on. Thus, as a portable C programmer, or a programmer of > portable C, you're used to this "at least" reasoning anyway. > > There are situations when you need some minimum width, and this is not > related to conforming to any external storage. Say you need a type to > hold a field of 30 bits. > > Before C99 inttypes, you might reach for the smallest standard type > that will yield at least that many bits, and that would be unsigned > long. > > However, unsigned long might be excessively wide, leading to wasted > storage. > > So, you might have a typedef for it, and some discipline for configuring > the typedef for different build targets. On this target, unsigned int, > on that one unsigned long. In my line of work, that is invariably what you would have (at least, for the more experienced programmers). Often such types would come with the toolchain, or perhaps with libraries that you use - if not, most professional embedded developers would at least have a set of fixed-size types in a common header that they always used. There might be one header for 8-bit 8051, one for 16-bit msp430, one for 32-bit 68k, and so on. Or there might be a single common header that makes use of <limits.h> and conditional compilation to handle it all automatically. The use of explicit fixed-size types has been standard since the first microcontroller developer tried C instead of assembly, but no one ever bothered making types equivalent to the "least" or "fast" types. (Though of course "int", "short", and "long" were used.) > > The type uint_least32_t typedef solves the problem: the target > implementation provides the type with the desired characteristics. > There is no problem to solve. "uint32_t" says you have 32 bits. Changing to "uint_least32_t" says you would swap the additional knowledge and clarity (which you may not need now, but may be of interest to others later) for a the promise of portability to a Cray supercomputer from the mid 1970's, and a pointless comment that you want this 32-bit number to be held in the smallest possible space. If your code needs portability to a DSP, then there are portability advantages in "uint_least8_t" and "uint_least16_t". But they are still almost certainly a bad idea as the results on a system with CHAR_BIT greater than 8 will probably not be optimal anyway. There is a lot more practical relevance of the "fast" types, but with the exception of "uint_fast8_t" in code that must be portable to 8-bit devices and bigger, you are usually clearer and better off using "int" or "unsigned int". > It's only one character longer than "unsigned long", and gets rid > of a mess of typedefs wrapped in #ifdefs and whatnot. > > When C99 was new, I would have avoided using it, but 23 years having > passed, it's okay to use in most programs that don't have to be > portable to ridiculously old installations. >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-14 03:09 +0100 |
| Message-ID | <87y1umr9k7.fsf@bsb.me.uk> |
| In reply to | #167678 |
David Brown <david.brown@hesbynett.no> writes: > But I don't think C is that kind of language, and I remain unconvinced > that heavy use of the "least" and "fast" types is anything more than > baby steps towards such abstractions. Is anyone suggesting heavy use of least and fast types? Is anyone suggesting such use would be even a tiny step towards data abstraction? I'm not. > (I am, I think, a little more > open to their use than I was before this subthread started, however.) That's interesting. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-14 10:29 +0200 |
| Message-ID | <tfs3ci$2rvtt$1@dont-email.me> |
| In reply to | #167693 |
On 14/09/2022 04:09, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> But I don't think C is that kind of language, and I remain unconvinced >> that heavy use of the "least" and "fast" types is anything more than >> baby steps towards such abstractions. > > Is anyone suggesting heavy use of least and fast types? No, the suggestions have been that in many cases it would have been better to use least or fast types instead of fixed size types. I appreciate the difference - it may have been even better (for some value of "better") to use other standard C types such as "int", or to use application-specific types. The reality is that fixed size types /are/ heavily used, at least in some types of programming (I am clearly biased by my own experience in a particular field). If these were to be replaced, in most cases, by least or fast types, then the result would necessarily be heavy use of least and fast types in such code. > Is anyone > suggesting such use would be even a tiny step towards data abstraction? > I'm not. > They /are/ a step more abstract than the fixed size types - their definition is in terms of functional features and not implementation features. >> (I am, I think, a little more >> open to their use than I was before this subthread started, however.) > > That's interesting. > Discussions like these make you think (well, they make /me/ think - I can't really answer for anyone else!). And if we think, with an open mind, then it should result in a better understanding of alternative ideas and opinions. That does not mean changing stances, or agreeing with other people's arguments. But it does mean that when you see a "uint32_t" variable in code that is not dictated by external forces, you might be less inclined to think it is "knee-jerk programming" and more inclined to consider that it might have been chosen carefully and intentionally instead of "uint_fast32_t" or "uint_least32_t". And when I next write code with a "uint32_t" variable, I will be more inclined to consider if "uint_fast32_t" or "uint_least32_t" better expresses my intentions, or improves portability or efficiency, and if that outweighs other considerations.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-14 15:14 +0100 |
| Message-ID | <87zgf2oxfn.fsf@bsb.me.uk> |
| In reply to | #167700 |
David Brown <david.brown@hesbynett.no> writes: > Discussions like these make you think (well, they make /me/ think - I > can't really answer for anyone else!). And if we think, with an open > mind, then it should result in a better understanding of alternative > ideas and opinions. That does not mean changing stances, or agreeing > with other people's arguments. But it does mean that when you see a > "uint32_t" variable in code that is not dictated by external forces, > you might be less inclined to think it is "knee-jerk programming" and > more inclined to consider that it might have been chosen carefully and > intentionally instead of "uint_fast32_t" or "uint_least32_t". Can you summarise your view so we can wrap this up? What is the thinking that supports the choice of an intN_t type rather than an int_(least|fast)N_t type (where there is no external driving force behind the choice)? A lot has been written by several contributors (I seem to be alone in having the option I stated) but I can't extract the core reasoning from all the posts. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-14 07:36 -0700 |
| Message-ID | <86pmfym392.fsf@linuxsc.com> |
| In reply to | #167711 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > David Brown <david.brown@hesbynett.no> writes: > >> Discussions like these make you think (well, they make /me/ think - I >> can't really answer for anyone else!). And if we think, with an open >> mind, then it should result in a better understanding of alternative >> ideas and opinions. That does not mean changing stances, or agreeing >> with other people's arguments. But it does mean that when you see a >> "uint32_t" variable in code that is not dictated by external forces, >> you might be less inclined to think it is "knee-jerk programming" and >> more inclined to consider that it might have been chosen carefully and >> intentionally instead of "uint_fast32_t" or "uint_least32_t". > > Can you summarise your view so we can wrap this up? What is the > thinking that supports the choice of an intN_t type rather than an > int_(least|fast)N_t type (where there is no external driving force > behind the choice)? > > A lot has been written by several contributors (I seem to be alone in > having the option I stated) but I can't extract the core reasoning from > all the posts. Not alone. As best I can recall I have silently nodded agreement with everything you have said in this subthread.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-10-03 01:10 -0700 |
| Message-ID | <9d411b65-5b30-4c00-97df-33b4a71d62aen@googlegroups.com> |
| In reply to | #167711 |
On Wednesday, 14 September 2022 at 17:14:34 UTC+3, Ben Bacarisse wrote: > David Brown <david...@hesbynett.no> writes: > > > Discussions like these make you think (well, they make /me/ think - I > > can't really answer for anyone else!). And if we think, with an open > > mind, then it should result in a better understanding of alternative > > ideas and opinions. That does not mean changing stances, or agreeing > > with other people's arguments. But it does mean that when you see a > > "uint32_t" variable in code that is not dictated by external forces, > > you might be less inclined to think it is "knee-jerk programming" and > > more inclined to consider that it might have been chosen carefully and > > intentionally instead of "uint_fast32_t" or "uint_least32_t". > > Can you summarise your view so we can wrap this up? What is the > thinking that supports the choice of an intN_t type rather than an > int_(least|fast)N_t type (where there is no external driving force > behind the choice)? > > A lot has been written by several contributors (I seem to be alone in > having the option I stated) but I can't extract the core reasoning from > all the posts. I do not know what the expected reasoning is. The "external driving force" is in practice rather major ... often it is all input and output. In sense that all input comes from external sources and all output goes to those. As all software is basically input, processing and output the usage of those least and fast types feels to be good for mild internal optimizations in that "processing" part.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-10-03 11:36 +0100 |
| Message-ID | <878rlxqjn0.fsf@bsb.me.uk> |
| In reply to | #167948 |
Öö Tiib <ootiib@hot.ee> writes: > On Wednesday, 14 September 2022 at 17:14:34 UTC+3, Ben Bacarisse wrote: >> David Brown <david...@hesbynett.no> writes: >> >> > Discussions like these make you think (well, they make /me/ think - I >> > can't really answer for anyone else!). And if we think, with an open >> > mind, then it should result in a better understanding of alternative >> > ideas and opinions. That does not mean changing stances, or agreeing >> > with other people's arguments. But it does mean that when you see a >> > "uint32_t" variable in code that is not dictated by external forces, >> > you might be less inclined to think it is "knee-jerk programming" and >> > more inclined to consider that it might have been chosen carefully and >> > intentionally instead of "uint_fast32_t" or "uint_least32_t". >> >> Can you summarise your view so we can wrap this up? What is the >> thinking that supports the choice of an intN_t type rather than an >> int_(least|fast)N_t type (where there is no external driving force >> behind the choice)? >> >> A lot has been written by several contributors (I seem to be alone in >> having the option I stated) but I can't extract the core reasoning from >> all the posts. > > I do not know what the expected reasoning is. The "external driving > force" is in practice rather major ... often it is all input and > output. Data can (usually) be read into, and output from, int_fastN_t objects just as easily as intN_t objects. > In sense that all input comes from external sources and all output > goes to those. As all software is basically input, processing and > output the usage of those least and fast types feels to be good for > mild internal optimizations in that "processing" part. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2022-10-04 02:13 -0700 |
| Message-ID | <8ba440c1-f327-483e-a0ac-129e412e6d12n@googlegroups.com> |
| In reply to | #167950 |
On Monday, 3 October 2022 at 13:36:18 UTC+3, Ben Bacarisse wrote: > 嘱 Tiib <oot...@hot.ee> writes: > > > On Wednesday, 14 September 2022 at 17:14:34 UTC+3, Ben Bacarisse wrote: > >> David Brown <david...@hesbynett.no> writes: > >> > >> > Discussions like these make you think (well, they make /me/ think - I > >> > can't really answer for anyone else!). And if we think, with an open > >> > mind, then it should result in a better understanding of alternative > >> > ideas and opinions. That does not mean changing stances, or agreeing > >> > with other people's arguments. But it does mean that when you see a > >> > "uint32_t" variable in code that is not dictated by external forces, > >> > you might be less inclined to think it is "knee-jerk programming" and > >> > more inclined to consider that it might have been chosen carefully and > >> > intentionally instead of "uint_fast32_t" or "uint_least32_t". > >> > >> Can you summarise your view so we can wrap this up? What is the > >> thinking that supports the choice of an intN_t type rather than an > >> int_(least|fast)N_t type (where there is no external driving force > >> behind the choice)? > >> > >> A lot has been written by several contributors (I seem to be alone in > >> having the option I stated) but I can't extract the core reasoning from > >> all the posts. > > > > I do not know what the expected reasoning is. The "external driving > > force" is in practice rather major ... often it is all input and > > output. > > Data can (usually) be read into, and output from, int_fastN_t objects > just as easily as intN_t objects. Perhaps exact bit width types (in what I/O usually goes) can be transformed to/from dim bit width types easily enough but the whole reasoning I put up is that there are (usually) no reason to and so int32_t is just less to type than int_fast32_t. > > In sense that all input comes from external sources and all output > > goes to those. As all software is basically input, processing and > > output the usage of those least and fast types feels to be good for > > mild internal optimizations in that "processing" part.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-10-04 16:27 +0100 |
| Message-ID | <87mtabpq10.fsf@bsb.me.uk> |
| In reply to | #167957 |
Öö Tiib <ootiib@hot.ee> writes: > On Monday, 3 October 2022 at 13:36:18 UTC+3, Ben Bacarisse wrote: >> 嘱 Tiib <oot...@hot.ee> writes: >> >> > On Wednesday, 14 September 2022 at 17:14:34 UTC+3, Ben Bacarisse wrote: >> >> David Brown <david...@hesbynett.no> writes: >> >> >> >> > Discussions like these make you think (well, they make /me/ think - I >> >> > can't really answer for anyone else!). And if we think, with an open >> >> > mind, then it should result in a better understanding of alternative >> >> > ideas and opinions. That does not mean changing stances, or agreeing >> >> > with other people's arguments. But it does mean that when you see a >> >> > "uint32_t" variable in code that is not dictated by external forces, >> >> > you might be less inclined to think it is "knee-jerk programming" and >> >> > more inclined to consider that it might have been chosen carefully and >> >> > intentionally instead of "uint_fast32_t" or "uint_least32_t". >> >> >> >> Can you summarise your view so we can wrap this up? What is the >> >> thinking that supports the choice of an intN_t type rather than an >> >> int_(least|fast)N_t type (where there is no external driving force >> >> behind the choice)? >> >> >> >> A lot has been written by several contributors (I seem to be alone in >> >> having the option I stated) but I can't extract the core reasoning from >> >> all the posts. >> > >> > I do not know what the expected reasoning is. The "external driving >> > force" is in practice rather major ... often it is all input and >> > output. >> >> Data can (usually) be read into, and output from, int_fastN_t objects >> just as easily as intN_t objects. > > Perhaps exact bit width types (in what I/O usually goes) can be > transformed to/from dim bit width types easily enough but the > whole reasoning I put up is that there are (usually) no reason to > and so int32_t is just less to type than int_fast32_t. Agreed. The only reasoning I've seen is "less typing" (unless I missed something along the way). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-13 11:48 -0700 |
| Message-ID | <87a673hzzj.fsf@nosuchdomain.example.com> |
| In reply to | #167662 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> While thinking about newer C features, I have found another challenge
> with using multiple different sometimes incompatible aliases for
> integer types - _Generic. I don't know if you've used _Generic much,
> but it can sometimes be useful. Here is a small example :
>
> #include <stdint.h>
> #include <inttypes.h>
> #include <stdio.h>
>
> #define print_var(_x) \
> do { \
> printf("Var " # _x " = "); \
> printf( \
> _Generic(_x, \
> uint8_t : "0x%02" PRIx8, \
> uint16_t : "0x%04" PRIx16, \
> uint32_t : "0x%08" PRIx32, \
> uint64_t : "0x%016" PRIx64), \
> _x); \
> printf("\n"); \
> } while (0);
I'd use the predefined types unsigned char, unsigned short, et al rather
than the uintN_t types. For example, if uint32_t is unsigned int and
uint64_t is unsigned long long, then passing an unsigned long argument
is an error. Using the predefined types guarantees that you'll cover
all the integer types. You can use sizeof to determine the number of
digits.
Except that it all breaks down if some of the types in <stdint.h> are
defined as extended integer types. There's no good way for a _Generic
expression to cover all the integer types if the implementation supports
extended integer types. (Then again, I'm not aware of any
implementations that do so.)
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-14 10:38 +0200 |
| Message-ID | <tfs3tn$2s1a8$1@dont-email.me> |
| In reply to | #167679 |
On 13/09/2022 20:48, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> While thinking about newer C features, I have found another challenge
>> with using multiple different sometimes incompatible aliases for
>> integer types - _Generic. I don't know if you've used _Generic much,
>> but it can sometimes be useful. Here is a small example :
>>
>> #include <stdint.h>
>> #include <inttypes.h>
>> #include <stdio.h>
>>
>> #define print_var(_x) \
>> do { \
>> printf("Var " # _x " = "); \
>> printf( \
>> _Generic(_x, \
>> uint8_t : "0x%02" PRIx8, \
>> uint16_t : "0x%04" PRIx16, \
>> uint32_t : "0x%08" PRIx32, \
>> uint64_t : "0x%016" PRIx64), \
>> _x); \
>> printf("\n"); \
>> } while (0);
>
> I'd use the predefined types unsigned char, unsigned short, et al rather
> than the uintN_t types. For example, if uint32_t is unsigned int and
> uint64_t is unsigned long long, then passing an unsigned long argument
> is an error. Using the predefined types guarantees that you'll cover
> all the integer types. You can use sizeof to determine the number of
> digits.
That is clearly also possible (as is Ben's alternative suggestion). The
point of my example was not to make a perfect, portable variable print
solution, but merely to illustrate a situation where a simple and neat
_Generic pattern breaks down if you include the fast and least types.
>
> Except that it all breaks down if some of the types in <stdint.h> are
> defined as extended integer types. There's no good way for a _Generic
> expression to cover all the integer types if the implementation supports
> extended integer types. (Then again, I'm not aware of any
> implementations that do so.)
>
I too don't know of any C implementations that actually have extended
integer types, but I know that on the AVR the <stdint.h> types are
defined as "int" and "unsigned int" with different sizes according to a
gcc extension. I have not looked at how that might affect _Generic.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-14 14:27 +0000 |
| Message-ID | <cxlUK.12702$C8y5.2221@fx07.iad> |
| In reply to | #167701 |
David Brown <david.brown@hesbynett.no> writes: >> >I too don't know of any C implementations that actually have extended >integer types, Does GCC's __uint128_t/__int128_t count as an extended integer type?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-14 07:58 -0700 |
| Message-ID | <87o7vigfzs.fsf@nosuchdomain.example.com> |
| In reply to | #167713 |
scott@slp53.sl.home (Scott Lurndal) writes:
> David Brown <david.brown@hesbynett.no> writes:
>>I too don't know of any C implementations that actually have extended
>>integer types,
>
> Does GCC's __uint128_t/__int128_t count as an extended integer type?
No, they're not documented as extended integer types, and they don't
meet all the requirements. For example, 36893488147419103232 (2**65) is
not a valid integer constant, and [u]intmax_t are 64 bits, not 128.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-16 13:06 -0700 |
| Message-ID | <86a66zkrrz.fsf@linuxsc.com> |
| In reply to | #167679 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>
>> While thinking about newer C features, I have found another challenge
>> with using multiple different sometimes incompatible aliases for
>> integer types - _Generic. I don't know if you've used _Generic much,
>> but it can sometimes be useful. Here is a small example :
>>
>> #include <stdint.h>
>> #include <inttypes.h>
>> #include <stdio.h>
>>
>> #define print_var(_x) \
>> do { \
>> printf("Var " # _x " = "); \
>> printf( \
>> _Generic(_x, \
>> uint8_t : "0x%02" PRIx8, \
>> uint16_t : "0x%04" PRIx16, \
>> uint32_t : "0x%08" PRIx32, \
>> uint64_t : "0x%016" PRIx64), \
>> _x); \
>> printf("\n"); \
>> } while (0);
>
> I'd use the predefined types unsigned char, unsigned short, et al rather
> than the uintN_t types. For example, if uint32_t is unsigned int and
> uint64_t is unsigned long long, then passing an unsigned long argument
> is an error. Using the predefined types guarantees that you'll cover
> all the integer types.
Yes, obviously using standard integer types is better than
considering just the exact width types.
> You can use sizeof to determine the number of digits.
It seems better to use values from <limits.h> to determine the
number of digits.
> Except that it all breaks down if some of the types in <stdint.h> are
> defined as extended integer types. There's no good way for a _Generic
> expression to cover all the integer types if the implementation supports
> extended integer types. [...]
There is a way to write a _Generic expression that covers all the
standard integer types; char; the real floating types; size_t;
ptrdiff_t; wchar_t; wint_t; [u]intmax_t; [u]intptr_t (if they
exist); [u]int_least{8,16,32,64}_t; [u]int_fast{8,16,32,64}_t;
and [u]int{8,16,32,64}_t (if they exist); with separate result
expressions for each type, and which will be accepted without
complaint regardless of which types may be extended integer
types. Assuming of course that someone thinks it's important to
do that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-16 13:16 -0700 |
| Message-ID | <877d23gjme.fsf@nosuchdomain.example.com> |
| In reply to | #167745 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>
>>> While thinking about newer C features, I have found another challenge
>>> with using multiple different sometimes incompatible aliases for
>>> integer types - _Generic. I don't know if you've used _Generic much,
>>> but it can sometimes be useful. Here is a small example :
>>>
>>> #include <stdint.h>
>>> #include <inttypes.h>
>>> #include <stdio.h>
>>>
>>> #define print_var(_x) \
>>> do { \
>>> printf("Var " # _x " = "); \
>>> printf( \
>>> _Generic(_x, \
>>> uint8_t : "0x%02" PRIx8, \
>>> uint16_t : "0x%04" PRIx16, \
>>> uint32_t : "0x%08" PRIx32, \
>>> uint64_t : "0x%016" PRIx64), \
>>> _x); \
>>> printf("\n"); \
>>> } while (0);
>>
>> I'd use the predefined types unsigned char, unsigned short, et al rather
>> than the uintN_t types. For example, if uint32_t is unsigned int and
>> uint64_t is unsigned long long, then passing an unsigned long argument
>> is an error. Using the predefined types guarantees that you'll cover
>> all the integer types.
>
> Yes, obviously using standard integer types is better than
> considering just the exact width types.
>
>> You can use sizeof to determine the number of digits.
>
> It seems better to use values from <limits.h> to determine the
> number of digits.
That has the advantage that it relies on the ranges of the types rather
than their sizes, and the disadvantage that it's harder and more
error-prone (and very likely not worth the effort) to compute how many
hexadecimal digits to use. It's *usually* reasonably safe to assume
there are no padding bit. And if, for example, unsigned short is 24
bits with 8 padding bits, using 6 hexadecimal digits is probably
harmless.
>> Except that it all breaks down if some of the types in <stdint.h> are
>> defined as extended integer types. There's no good way for a _Generic
>> expression to cover all the integer types if the implementation supports
>> extended integer types. [...]
>
> There is a way to write a _Generic expression that covers all the
> standard integer types; char; the real floating types; size_t;
> ptrdiff_t; wchar_t; wint_t; [u]intmax_t; [u]intptr_t (if they
> exist); [u]int_least{8,16,32,64}_t; [u]int_fast{8,16,32,64}_t;
> and [u]int{8,16,32,64}_t (if they exist); with separate result
> expressions for each type, and which will be accepted without
> complaint regardless of which types may be extended integer
> types. Assuming of course that someone thinks it's important to
> do that.
You go to the effort to tell us it's possible, but not to tell us how.
I'm not interested in being assigned homework. Explain it or don't.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-12 17:55 +0000 |
| Message-ID | <voKTK.6182$NNy7.4129@fx39.iad> |
| In reply to | #167644 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>David Brown <david.brown@hesbynett.no> writes:
>> I think to some extent it comes down to a subjective opinion of what
>> we are willing to be wrong about and what we prefer to be correct
>> about in how we code. There are always compromises.
>
>What are some good examples if the use of the intN_t types?
The main codebase I've been working with for the last decade
or so is a full-system simulator that simulates an SoC with
dozens of ARMv9 cores, a bunch of hardware accelerators for
packet processing (multiple 100Gb ethernet ports) and signal
processing for 5G wireless systems.
When the hardware entity is 32-bits wide, and is used as an
unsigned value, then uint32_t is the natural and proper type
to use. For example,the ARM core general purpose register file is
defined as uint64_t, as all the general purpose registers are
64-bits wide. The advSIMD (NEON) register file is defined
using the gcc extension __uint128_t.
When accessing arrays of bytes in the simulated memory, uint8_t
is the natural type to use.
When representing a composite hardware data structure (such as
an error record or mapping table entry) as a C/C++ structure,
the appopriate width types (and a compiler specific PACKED attribute)
are both useful.
e.g
/* ARM SMMUv3 Bad StreamID event message */
struct SMMU_C_BAD_STREAMID_S_s {
#if __BYTE_ORDER == __BIG_ENDIAN
uint64_t streamid : 32; /**< [ 63: 32] Stream ID value. */
uint64_t substreamid : 20; /**< [ 31: 12] Substream ID value. */
uint64_t ssv : 1; /**< [ 11: 11] Substream ID valid. */
uint64_t reserved_8_10 : 3;
uint64_t code : 8; /**< [ 7: 0] Event code. */
#else
uint64_t code : 8;
uint64_t reserved_8_10 : 3;
uint64_t ssv : 1;
uint64_t substreamid : 20;
uint64_t streamid : 32;
#endif
uint64_t reserved_64_127 : 64;
uint64_t reserved_128_191 : 64;
uint64_t reserved_192_255 : 64;
} s;
(The above was generated from a YAML file which contained
enumerations, structure and register definitions (converted from IPXACT XML)).
I would never find the _leastN types useful.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web