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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-13 18:47 +0100 |
| Message-ID | <tfqfng$p2i$1@gioia.aioe.org> |
| In reply to | #167675 |
On 13/09/2022 16:50, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >> Wouldn't it better to try minimising the range of types than >> advocating using even more? > > I am not advocating for more. Again that's just the spin you want to > put in my post. But not for fewer either! C has far too many including all the 'least' ones you seem to be in favour of. These are the typical requirements: (1) A "don't care" int type (2) A byte type (most ideally unsigned) for things like representing UTF8 strings (3) A specific-width integer For (1), C's 'int' at 32 bits is too narrow IMV for current 64-bit machines. Overflow is a very real issue. And actually, it might even be 16 bits. For (2), C offers 'unsigned char' or 'uint8_t' For (3), C offers the int32_t family This is a poor enough choice, made worse by the proliferation of types that may or may not be compatible, and the difficulties of using printf/scanf codes, or constructing literals, for those _t types. But you want to make it worser by suggesting people use 'least' types. Put this way, it's become a lot clearer to me why so many apps want to clear up the mess (only partially as they can't fix printf or magically make 726163 a 64-bit value) by superimposing their own types that they can have a lot more confidence in and whose denotations are less severe in their appearance. Other languages mostly offer a better selection and more pleasing typenames, except for (1), where either it only has width-specific types (i32, Int64), or the 'Int' type is still 32 bits. I believe this is C's influence still. A few might offer 64 bits without needing to use 'Long', but I couldn't tell you off-hand (other than mine of course).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-14 03:16 +0100 |
| Message-ID | <87sfkur98j.fsf@bsb.me.uk> |
| In reply to | #167677 |
Bart <bc@freeuk.com> writes: > On 13/09/2022 16:50, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> Wouldn't it better to try minimising the range of types than >>> advocating using even more? >> I am not advocating for more. Again that's just the spin you want to >> put in my post. > > But not for fewer either! No, as that would break existing code. > C has far too many including all the 'least' > ones you seem to be in favour of. I am saying they should be used in preference to intN_t types in certain (specified) situations. You can't possibly not know my position by now, surely? This is just more spin. I rarely use them. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-13 20:15 +0200 |
| Message-ID | <tfqhcm$2l21g$1@dont-email.me> |
| In reply to | #167675 |
On 13/09/2022 17:50, Ben Bacarisse wrote: > I think you are misunderstanding. We should have a term for the use of > a fixed-width type intended to match something externally defined -- a > network header field, as OS structure, data in some fixed file format. > This use is 100% justified. It is, in my view, the main reason these > types exist. Let's call this is a "matching use". In a different kind of language, I'd like to see a clear distinction between different purposes of types. There could be a general "integer" whose range was inferred by the compiler as necessary, useful for local variables when you need counting, arithmetic, indexing, etc., but have no interest in the implementation details. Concrete integer types used for communicating with the outside - file structures, foreign function interfaces, etc., - would be explicitly fixed sizes and representations, but not support operations other than loading and storing. These could also be used for data storage (in particular, structs, arrays, and arrays of structs) where size is relevant. And then you could make your own integer types that are explicit subranges of "integer", along with properties such as wrapping behaviour. Ada, I think, can do this kind of thing - as can C++, if you make appropriate class templates (though you can't get rid of the built-in types and behaviours). 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.)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-09-13 20:29 +0000 |
| Message-ID | <20220913131411.121@kylheku.com> |
| In reply to | #167678 |
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. The type uint_least32_t typedef solves the problem: the target implementation provides the type with the desired characteristics. 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. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-13 22:22 +0100 |
| Message-ID | <tfqsa1$bb0$1@gioia.aioe.org> |
| In reply to | #167680 |
On 13/09/2022 21: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.
>
> The type uint_least32_t typedef solves the problem: the target
> implementation provides the type with the desired characteristics.
You said you need a field of 30 bits, so how would uint_least32_t be
better than uint_32t?
> 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.
On Fortran IV in the 1970s (at least on byte-addressed machines), you
got fixed-width integers with:
integer*4
The 4 is the number of bytes it occupied. An unsized 'integer' would be
some default, probably the machine word size. This is about the time of
the original C, and really wasn't that difficult a concept.
(I used the same idea from the 80s: int*4 or int:32 for byte/bit counts,
or byte*4 etc for unsigned. I've moved on from that syntax, but I was
also long aware of a need for such types in low level code.
C took until C99 to have such a thing, and, as typically implemented in
stdint.h, it looks a complete hack. Eg. defining precise types on top of
imprecise ones, or creating unpredictable aliases.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-13 14:37 -0700 |
| Message-ID | <875yhrhs5o.fsf@nosuchdomain.example.com> |
| In reply to | #167681 |
Bart <bc@freeuk.com> writes:
[...]
> You said you need a field of 30 bits, so how would uint_least32_t be
> better than uint_32t?
[...]
It's guaranteed to exist.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-13 23:16 +0100 |
| Message-ID | <tfqvf2$1f88$1@gioia.aioe.org> |
| In reply to | #167682 |
On 13/09/2022 22:37, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> You said you need a field of 30 bits, so how would uint_least32_t be >> better than uint_32t? > [...] > > It's guaranteed to exist. > You mean, in the same way that it is better to use trigraphs ??( and ??) instead of [ and ], because they are guaranteed to be available? You might then appreciate how doing that would adversely affect readability in the 99.99% of cases where [ and ] would have been perfectly fine. I have no great love for C as people here will know, but why the desire to drag the language down by keeping it bogged down in this stuff? (I have enough problems with those basic intN_t types in managing to write them without a typo - see above!)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-13 22:16 +0000 |
| Message-ID | <tj7UK.110566$6gz7.110355@fx37.iad> |
| In reply to | #167683 |
Bart <bc@freeuk.com> writes: >On 13/09/2022 22:37, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >> [...] >>> You said you need a field of 30 bits, so how would uint_least32_t be >>> better than uint_32t? >> [...] >> >> It's guaranteed to exist. >> > >You mean, in the same way that it is better to use trigraphs ??( and ??) >instead of [ and ], because they are guaranteed to be available? Maybe he was refering to your mis-spelling of uint32_t?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-13 16:15 -0700 |
| Message-ID | <87wna6hnmc.fsf@nosuchdomain.example.com> |
| In reply to | #167684 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Bart <bc@freeuk.com> writes:
>>On 13/09/2022 22:37, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> You said you need a field of 30 bits, so how would uint_least32_t be
>>>> better than uint_32t?
>>> [...]
>>>
>>> It's guaranteed to exist.
>>>
>>
>>You mean, in the same way that it is better to use trigraphs ??( and ??)
>>instead of [ and ], because they are guaranteed to be available?
>
> Maybe he was refering to your mis-spelling of uint32_t?
No, I saw that and ignored it.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-13 16:15 -0700 |
| Message-ID | <871qsej27e.fsf@nosuchdomain.example.com> |
| In reply to | #167683 |
Bart <bc@freeuk.com> writes:
> On 13/09/2022 22:37, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> You said you need a field of 30 bits, so how would uint_least32_t be
>>> better than uint_32t?
>> [...]
>> It's guaranteed to exist.
>
> You mean, in the same way that it is better to use trigraphs ??( and
> ??) instead of [ and ], because they are guaranteed to be available?
[...]
No, I mean that you asked a question and I answered it.
I understand that you don't like the names. If uint32_t were called
uint_exact32_t, would you agree that uint_least32_t might be better than
uint_exact32_t in that context?
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-14 10:58 +0100 |
| Message-ID | <tfs8kn$1rqs$1@gioia.aioe.org> |
| In reply to | #167689 |
On 14/09/2022 00:15, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 13/09/2022 22:37, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>> [...] >>>> You said you need a field of 30 bits, so how would uint_least32_t be >>>> better than uint_32t? >>> [...] >>> It's guaranteed to exist. >> >> You mean, in the same way that it is better to use trigraphs ??( and >> ??) instead of [ and ], because they are guaranteed to be available? > [...] > > No, I mean that you asked a question and I answered it. > > I understand that you don't like the names. If uint32_t were called > uint_exact32_t, would you agree that uint_least32_t might be better than > uint_exact32_t in that context? > Few like the names, and there would be a revolt I think if a u32 type had to be written as uint_exact32_t. A lot more would just create their own typedefs than already do. (It has already been suggested for int_least32_t.) But wasn't the purpose of stdint.h to stop the practice of everyone inventing their own typenames for i8-u64/u8-u64? Instead it's encouraging people to do so! For uint_least32_t it isn't just the unwieldy name, it's the rather odd concept that it introduces that makes you think. I understand that the main use of such a type (let's call it u32+ for short), is for when C is used on machines that doesn't have a native u32 type, not even expressed as two u16 words. Apart from DSPs (which still mainly have power-of-two word sizes, but some may only offer 64 bits), I'm only aware of ancient mainframes where they might be employed (eg. PDP10 with 36-bit words, which I've used, and CDC6600 with 60-bits, which I haven't). On those, u32+ may be implemented as 36 or 60 bits; u32 would, what, generate an error? (PDP10 did however offer packed 6- and 7-bit characters with special instructions; here uint_least8_t would not help; it would make less effective use of memory, and couldn't represent 6- and 7-bit text used elsewhere.) OK, if there is likelyhood, or, more probably, you KNOW, that you will be using such a target, then sure, use a special type u32+ or typedefed version of the full form (I would just call it 'intm' as I have done elsewhere). But Ben, as I understood (he will doubtless accuse me of misrepresenting his words), was suggesting using Least types as a matter of routine, irrespective of target machine.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-14 15:36 +0100 |
| Message-ID | <87tu5aowf9.fsf@bsb.me.uk> |
| In reply to | #167703 |
Bart <bc@freeuk.com> writes: > But Ben, as I understood (he will doubtless accuse me of > misrepresenting his words), was suggesting using Least types as a > matter of routine, irrespective of target machine. Well, yes, but also the fast ones depending on whether storage or speed is the issue. I can't see the point of asking for exactly N bits (with no padding and two's complement negatives) except when matching some external data structure. (And there's also the exception for the N-bit unsigned types where the wrapping is exactly what the algorithm needs.) Programmers used to complain that they didn't know whether to use short or int or long or long long because they need 32 bits but they don't want to waste space -- use int_least32_t -- or that they don't want to slow the code down by insisting on 32 bits if a wider type is faster -- use int_fast32_t. These types arose to answer these complaints. I am surprised their use is so controversial. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.com> |
|---|---|
| Date | 2022-09-14 21:53 +0100 |
| Message-ID | <tftf10$33a1m$1@dont-email.me> |
| In reply to | #167714 |
On 14/09/2022 15:36, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> But Ben, as I understood (he will doubtless accuse me of >> misrepresenting his words), was suggesting using Least types as a >> matter of routine, irrespective of target machine. > > Well, yes, but also the fast ones depending on whether storage or speed > is the issue. > > I can't see the point of asking for exactly N bits (with no padding and > two's complement negatives) except when matching some external data > structure. (And there's also the exception for the N-bit unsigned types > where the wrapping is exactly what the algorithm needs.) > > Programmers used to complain that they didn't know whether to use short > or int or long or long long because they need 32 bits but they don't > want to waste space -- use int_least32_t -- or that they don't want to > slow the code down by insisting on 32 bits if a wider type is faster -- > use int_fast32_t. These types arose to answer these complaints. I am > surprised their use is so controversial. > I rather suspect the the complaint boils down to: it's too much to type.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-09-14 05:55 +0000 |
| Message-ID | <20220913224818.803@kylheku.com> |
| In reply to | #167683 |
On 2022-09-13, Bart <bc@freeuk.com> wrote: > On 13/09/2022 22:37, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >> [...] >>> You said you need a field of 30 bits, so how would uint_least32_t be >>> better than uint_32t? >> [...] >> >> It's guaranteed to exist. >> > > You mean, in the same way that it is better to use trigraphs ??( and ??) > instead of [ and ], because they are guaranteed to be available? Even if you suspect that your program will have to be manipulated in some environment where those characters are missing, that doesn't mean you have to use trigraphs. A file can be converted to trigraphs by machine. > You might then appreciate how doing that would adversely affect > readability in the 99.99% of cases where [ and ] would have been > perfectly fine. uint_least32_t need only appear in your code once: typedef uint_least32_t foo_bits_t; -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-14 10:10 +0200 |
| Message-ID | <tfs291$2rt4s$1@dont-email.me> |
| In reply to | #167696 |
On 14/09/2022 07:55, Kaz Kylheku wrote: > On 2022-09-13, Bart <bc@freeuk.com> wrote: >> You might then appreciate how doing that would adversely affect >> readability in the 99.99% of cases where [ and ] would have been >> perfectly fine. > > uint_least32_t need only appear in your code once: > > typedef uint_least32_t foo_bits_t; > That is a good point. A key issue for all these types is what the name says, and what emphasis it gives - what does it say about the relative importance of various aspects and features of the type? "uint32_t" says "this is an unsigned 32-bit integer". It does not emphasis speed, or small size, or precise size (unlike a "uint_exact32_t"). It's a type for working with numbers that can be up to 32-bit in size. 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. But when you use the type "foo_bits_t", you are telling the reader this is a variable for storing "foo_bits". That is much more useful information. And it might have been relevant, when defining "foo_bits_t", to tell the reader that minimising space is a critical feature of the storage of "foo_bits".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-14 07:54 -0700 |
| Message-ID | <87sfkugg5e.fsf@nosuchdomain.example.com> |
| In reply to | #167699 |
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. Perhaps if the types were called uint_exact32_t,
uint_fast32_t, and uint_least32_t, more programmers would decide which
one to use based on the actual characteristics of the types rather than
the lengths of their names.
[...]
--
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 18:32 +0200 |
| Message-ID | <tfsvmb$31f8s$1@dont-email.me> |
| In reply to | #167718 |
On 14/09/2022 16:54, Keith Thompson 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. > I'd rather the compiler made that choice itself, at least for local variables where the true size does not affect observable behaviour. If 64-bit gives the same "as if" result as 32-bit, but is more efficient, that's an optimisation issue - not a detail I want to worry about in code. When programming for 64-bit targets, do you usually use "long long int" as a common type (at least for local variables), rather than "int", just because it is faster on some 64-bit targets and unlikely to be slower? (I note that "uint_fast32_t" is 64-bit on most 64-bit targets, according to my testing on godbolt.org.) > It's may not have been the best decision to use the shorter names for > the exact types. Perhaps if the types were called uint_exact32_t, > uint_fast32_t, and uint_least32_t, more programmers would decide which > one to use based on the actual characteristics of the types rather than > the lengths of their names. > (With vague terms and speculation about what might have been, much of this is no more than gut feeling.) I think you are right that there would have been more use of "fast" or "least" types had the size-specific types been called "exact", but I don't think it would have been very much different. The simple fact is that a lot of programmers like to be explicit and precise about some things, even if it is not really necessary for the code. They like to know what they are getting, at least for low level languages. A major reason people choose C rather than C++ is, rightly or wrongly, the impression that C gives you what you ask, while C++ does things behind your back. C programmers, on the whole, like the idea that when they say 32 bits, they get 32 bits. So I believe they would pick "uint_exact32_t" over "uint_least32_t" and "uint_fast32_t" in most cases. It is not surprising that most other languages aimed at low-level programming only have size-specific (and usually explicitly named) integer types as their fundamental integer types. Programmers simply are not particularly interested in using weaker specified types when the precise ones are available. An argument about what programmers actually use, is of course not an argument for what might be a better choice in any given case - millions of programmers /can/ be wrong at the same time. But familiarity and common practice is also a benefit to consider when choosing the "best" type for a purpose. I realise that the definition of "uint32_t" has exact size as an important feature. But that doesn't mean it is the most important feature when I choose to use it - though it is certainly sometimes the case. (Similarly, it has other features such as wrapping overflow that I generally do not rely on and would be happy not to have.) Often, it is just the simplest or default 32-bit unsigned integer type, and therefore a good choice when there is no outstanding reason to pick something else. Of course, my opinions may be somewhat biased by the fact that in almost all my programming, "uint32_t", "uint_least32_t" and "uint_fast32_t" have the same size. (Weirdly, on 32-bit ARM at least, they are not all the same type - two are "unsigned long" and one is "unsigned int".)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-14 18:39 +0100 |
| Message-ID | <tft3jt$1ie2$1@gioia.aioe.org> |
| In reply to | #167718 |
On 14/09/2022 15:54, Keith Thompson 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. > It's may not have been the best decision to use the shorter names for > the exact types. Perhaps if the types were called uint_exact32_t, > uint_fast32_t, and uint_least32_t, more programmers would decide which > one to use based on the actual characteristics of the types rather than > the lengths of their names. Seriously? Here is the result of a brief survey of languages that offer exact-width signed integer types from 8 to 64 bits: Bits: 8 16 32 64 C int8_t int16_t int32_t int64_t C (least) int_least8_t int_least16_t int_least32_t int_least64_t C (fast) int_fast8_t int_fast16_t int_fast32_t int_fast64_t C (proposed) int_exact8_t int_exact16_t int_exact32_t int_exact64_t D byte short int long Java byte short int long C# sbyte short int long Rust i8 i16 i32 i64 Zig i8 i16 i32 i64 Nim int8 int16 int32 int64 Go int8 int16 int32 int64 Julia Int8 Int16 Int32 Int64 C's exact C99 types are already at a disadvantage with that ugly _t suffix. Now people are not only advocating used of the types in the next rows, but suggesting the first is replaced by those new exact types. Just LOOK at them! I've had to space things out just to accomodate them. And, because even those int8_t types are so hackish, C already suffers from poor support for those types for: * Printing * Reading * Constants * MIN and MAX values which are 'implemented' with hundreds of obscure macros that probably no one bothers to use. C23 has added new types which I'm sure cannot just be lazily created with 'typedef' on top of existing ones; why didn't C99 do the same? (BTW my syntax allows either of the styles in the last 5 rows, and being case-insensitive, any of those denotations could be used directly.)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-09-15 01:12 +0000 |
| Message-ID | <20220914180404.544@kylheku.com> |
| In reply to | #167722 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-15 09:11 +0200 |
| Message-ID | <tfuj7j$38pn6$1@dont-email.me> |
| In reply to | #167730 |
On 15/09/2022 03:12, Kaz Kylheku wrote:
> 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.
This is an unfortunate complication, yes. The idea that /character/
types can be used for arithmetic, and that they can be used for
low-level memory access, is completely bonkers. It is the result of
quick fixes and workarounds for historical usage of the language. (Such
things are inevitable in any well-used language over time - the needs of
the language change, but you have to keep support for existing code.)
C++ has introduced a better solution - a std::byte type that can be used
as a general memory access type. This is a significantly better name
than "unsigned char".
It is not at all uncommon to assume "uint8_t" has the aliasing power of
character types - because on all platforms current and foreseeable
future, "uint8_t" is "unsigned char". Your risk of undefined behaviour
is hypothetical. (It is still better to use unsigned char or a typedef
thereof, because "correct by design" beats merely "always correct in
practice".)
I would prefer that character types, and (u)int8_t, did /not/ have
special memory aliasing features, and were not used for memcpy and
friends - they are inappropriate types for the job. I would rather see
a type "byte_t" that is an "alias everything" type of size one C byte.
And I would like a set of "mem8_t" up to "mem64_t" with the same
properties, but fixed sizes, for when you want to be sure your low-level
memory accesses have a particular access size. None of these types
should support arithmetic operations. (C++ std::byte does not support
arithmetic, though it supports some bitwise operations for masking.)
I've used such types myself, using gcc's "may_alias" attribute, but it
would be nice to see them standardised.
Of course, it's worth remembering that in practice, few compilers
optimise on the assumption that different types do not alias, other than
gcc and clang. And on low-level code it is not uncommon to use
"-fno-strict-aliasing" to say that all types alias each other. It turns
out that in practice, the opportunities for type-based alias analysis in
C are low, and the gains are very minor. (You might get more in C++.)
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web