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 | 15 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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2022-09-12 18:22 +0000 |
| Message-ID | <20220912111913.443@kylheku.com> |
| In reply to | #167653 |
On 2022-09-12, Scott Lurndal <scott@slp53.sl.home> wrote: > When accessing arrays of bytes in the simulated memory, uint8_t > is the natural type to use. I would say, unsigned char. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-12 20:41 +0100 |
| Message-ID | <87zgf4v0r5.fsf@bsb.me.uk> |
| In reply to | #167653 |
scott@slp53.sl.home (Scott Lurndal) writes: > 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. I can see there's going to be a lot of snipped, out of context replies. I sometimes try to avoid this by repeating the key exception as often as possible but it makes for very repetitive writing so I did not bother. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-11 15:45 -0700 |
| Message-ID | <87pmg1il7h.fsf@nosuchdomain.example.com> |
| In reply to | #167605 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> In fact may programmers are, in effect, using the "least" types because
> int really means int_least16_t and long means int_least32_t.
Not quite. A lot of implementations have 16-bit short and 32-bit int,
which means that int_least16_t *cannot* be defined as int. (int is at
least 16 bits, but it's not necessarily the narrowest 16+ bit type.)
And an implementation with 32-bit int and 48-bit long cannot define
int_least32_t as long.
--
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-11 15:41 -0700 |
| Message-ID | <87tu5dilfn.fsf@nosuchdomain.example.com> |
| In reply to | #167598 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> The "fast" and "least" types /do/ have their uses. There are not many
> targets that don't support 8-bit char and everything else as a power
> of 8 bits, but there /are/ a few. The main class of exceptions are
> DSP processors, and some highly specialised task-specific embedded
> processors. With C23, I believe types (u)int8_t, (u)int16_t,
> (u)int32_t and (u)int64_t have become mandatory - a target that does
> not support these natively must simulate them. This renders the
> "least" types obsolete.
No, the [u]intN_t types are still required only if they're supported.
N3054 7.22.1.1p3:
If an implementation provides standard or extended integer types
with a particular width and no padding bits, it shall define the
corresponding typedef names.
C23 does mandate 2's-complement for all integer types, but it still
allows padding bits and doesn't mandate any exact sizes.
--
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-12 17:06 +0200 |
| Message-ID | <tfnhub$29fjr$1@dont-email.me> |
| In reply to | #167621 |
On 12/09/2022 00:41, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> The "fast" and "least" types /do/ have their uses. There are not many >> targets that don't support 8-bit char and everything else as a power >> of 8 bits, but there /are/ a few. The main class of exceptions are >> DSP processors, and some highly specialised task-specific embedded >> processors. With C23, I believe types (u)int8_t, (u)int16_t, >> (u)int32_t and (u)int64_t have become mandatory - a target that does >> not support these natively must simulate them. This renders the >> "least" types obsolete. > > No, the [u]intN_t types are still required only if they're supported. > > N3054 7.22.1.1p3: > If an implementation provides standard or extended integer types > with a particular width and no padding bits, it shall define the > corresponding typedef names. > > C23 does mandate 2's-complement for all integer types, but it still > allows padding bits and doesn't mandate any exact sizes. > I must have misread something - perhaps in a list of proposed features for C23, or someone else's incorrect summary. I've repeated the same mistake in other posts too - my apologies if I've mislead anyone. Thanks for the correction. (Of course, in practical terms these types ar mandatory for all but the most niche of targets, such as some DSP's.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-11 06:46 -0700 |
| Message-ID | <868rmqqb0c.fsf@linuxsc.com> |
| In reply to | #167587 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > David Brown <david.brown@hesbynett.no> writes: [suggestion to use uint8_t and uint32_t in place of (my earlier use of) unsigned char and unsigned int] >> There are some real-world C implementations that do not have uint8_t >> and/or uint32_t, but the overlap in code between these niche systems >> and "normal" systems is almost non-existent. So the use of >> "uint_least8_t", "uint_fast32_t" and similar types is IMHO needless >> complication and verbosity, and certainly not something beginners >> should need to bother about. > > Really? That's a complication? > > Being a beginners is another matter. We don't know what sort of > beginner this is (I think it was a drive-by anyway), but none of the > types is ideal for a beginner. In fact, I imagine that's partly what > motivated TR's choice. Quite so.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-11 06:57 -0700 |
| Message-ID | <864jxeqahv.fsf@linuxsc.com> |
| In reply to | #167577 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Mind you, since char is guaranteed to be at least 8 bits wide, > unsigned char is effectively uint_least8_t. Note that these two types might not be the same type. The C standard allows the possibility that uint_least8_t might be an extended integer type, distinct from the standard integer type unisigned char. This distinction matters both because of pointer compatibility and because the standard character types get special treatment under the anti-aliasing rules. AFAICT there is never any reason to use uint_least8_t, except in those rare cases when uint_least8_t is used by virtue of needing to call a third-party library (and in that case it is likely that a poor choice was made by developers of that library).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-11 07:07 -0700 |
| Message-ID | <86zgf6ovhd.fsf@linuxsc.com> |
| In reply to | #167563 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> ManyBeers <markzuffi@yahoo.com> writes:
>>
>>> Hello I am teaching myself C and I need some help with a problem.
>>> After a search for dec/oct convert I found this code:
>>>
>>> [..code..]
>>
>> I would like to offer a different kind of answer to your
>> questions. First a suggestion: for this kind of problem I think
>> you will find it helpful to use unsigned types exclusively. In
>> the code below we will need (besides a plain 'unsigned' here and
>> there) two types, one for 8-bit values and one for 32-bit values:
>>
>> typedef unsigned char UC;
>> typedef unsigned int UI;
>
> There already standard perfectly cromulent typedefs for both,
> uint8_t and uint32_t.
For the posted response and example I think unsigned {char,int}
are better suited.
Furthermore, whether cromulent or not, IMO anyone who writes
uint8_t or uint32_t in open code should be shot.[*] YMMV.
[*] For more information please refer to the PDP-10 assembly
language style guide.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2022-09-11 14:18 +0000 |
| Subject | Neologism (Was: Beginner....Decimal/Octal converter help) |
| Message-ID | <tfkqo4$1bau9$1@news.xmission.com> |
| In reply to | #167603 |
In article <86zgf6ovhd.fsf@linuxsc.com>,
...
>Furthermore, whether cromulent or not, IMO anyone who writes
>uint8_t or uint32_t in open code should be shot.[*]
Found at:
https://en.wikipedia.org/wiki/Lisa_the_Iconoclast#Embiggen_and_cromulent
Cromulent is an adjective that was coined by David X. Cohen. Since it was
coined, it has appeared in Dictionary.com's 21st Century Lexicon. The
meaning of cromulent is inferred only from its usage, which indicates that it
is a positive attribute. Dictionary.com defines it as meaning 'fine' or
'acceptable'. Ben Macintyre has written that it means "valid or acceptable".
--
(Cruz certainly has an odd face) ... it looks like someone sewed pieces of a
waterlogged Reagan mask together at gunpoint ...
http://www.rollingstone.com/politics/news/how-america-made-donald-trump-unstoppable-20160224
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-11 16:33 +0000 |
| Message-ID | <g5oTK.408091$iiS8.306081@fx17.iad> |
| In reply to | #167603 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> ManyBeers <markzuffi@yahoo.com> writes:
>>>
>>>> Hello I am teaching myself C and I need some help with a problem.
>>>> After a search for dec/oct convert I found this code:
>>>>
>>>> [..code..]
>>>
>>> I would like to offer a different kind of answer to your
>>> questions. First a suggestion: for this kind of problem I think
>>> you will find it helpful to use unsigned types exclusively. In
>>> the code below we will need (besides a plain 'unsigned' here and
>>> there) two types, one for 8-bit values and one for 32-bit values
:
>>>
>>> typedef unsigned char UC;
>>> typedef unsigned int UI;
>>
>> There already standard perfectly cromulent typedefs for both,
>> uint8_t and uint32_t.
>
>For the posted response and example I think unsigned {char,int}
>are better suited.
You said, and I quote:
"two types, one for 8-bit values and one for 32-bit values
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-13 15:40 -0700 |
| Message-ID | <86o7vioq3d.fsf@linuxsc.com> |
| In reply to | #167614 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> ManyBeers <markzuffi@yahoo.com> writes:
>>>>
>>>>> Hello I am teaching myself C and I need some help with a problem.
>>>>> After a search for dec/oct convert I found this code:
>>>>>
>>>>> [..code..]
>>>>
>>>> I would like to offer a different kind of answer to your
>>>> questions. First a suggestion: for this kind of problem I think
>>>> you will find it helpful to use unsigned types exclusively. In
>>>> the code below we will need (besides a plain 'unsigned' here and
>>>> there) two types, one for 8-bit values and one for 32-bit values
>
> :
>
>>>> typedef unsigned char UC;
>>>> typedef unsigned int UI;
>>>
>>> There already standard perfectly cromulent typedefs for both,
>>> uint8_t and uint32_t.
>>
>> For the posted response and example I think unsigned {char,int}
>> are better suited.
>
> You said, and I quote:
>
> "two types, one for 8-bit values and one for 32-bit values
Yes, and I also said "unsigned {char,int} are better suited"
for the posted response and example. The quoted phrase was
put in to provide non-restrictive information about the two
types being used, and not to give a specification for those
types, which were given elsewhere in the posting.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-09 23:08 +0000 |
| Message-ID | <cIPSK.45075$SMP5.39069@fx05.iad> |
| In reply to | #167553 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
>ManyBeers <markzuffi@yahoo.com> writes:
>>int convertDecimalToOctal(int decimalNumber);
>
> The following program tries to convert the number given in main
> to its octal representation, which is printed to standard output.
>
> I wrote it just to the point where it seems to work for this
> special case, but I'm not convinced that it will print the
> correct result in all cases or does not overflow any of its
> buffers!
>
>#include <stdio.h>
>#include <string.h>
>
>/* are there digits above 0 in the buffer? */
>int digits_in( char buffer[] )
>{ size_t i = 0;
> for( ; i < strlen( buffer )&& buffer[ i ]=='0'; ++i );
> return buffer[ i ]> '0' && buffer[ i ]<= '9'; }
>
>/* write div to "result" and returns the remainder */
>int divrem
>( char dividend[], char result[], int base_of_dividend, int divisor )
>{ { size_t i = 0;
> for( ; i < strlen( dividend ); ++i )
> result[ i ]= ' '; result[ i ]= 0; }
> int r = 0; int j = 0; int k = 0;
> for( size_t i = 0; i < strlen( dividend ); ++i )
> { if( dividend[ i ]!= ' ' )
> { r = r * base_of_dividend + dividend[ i ]- '0';
> if( r >= divisor )
> { int const q = r/divisor; r = r%8;
> result[ j ]=( char )( q + '0' ); }
> else
> { result[ j ]='0'; }} ++j; }
> return r; }
>
>/* convert number, which is given in the base_of_dividend into
>base_of_result */
>void convert
>( char number[], char buffer[],
> int base_of_dividend,
> int base_of_result /* must not be larger than base_of_dividend */ )
>{ if( digits_in( number ))
> { int const digit =
> divrem( number, buffer, base_of_dividend, base_of_result );
> { convert( buffer, number, base_of_dividend, base_of_result );
> putchar( '0' + digit ); }}}
>
>int main( void )
>{ /* source in dec */
> char a[] = "897528309349537459261193475234783479487034102857389475930";
> /* the buffer must at least have a's len */
> char b[] = " ";
> convert( a, b, 10, 8 );
> putchar( '\n' ); }
>
>
Somewhat more concisely:
$ cat /tmp/octal.c
#include <stdint.h>
#include <stdio.h>
#include <string.h>
int
main(int argc, const char **argv, const char **envp)
{
char buf[64];
char *bp = &buf[64];
uint64_t value;
if (argc > 1) value = strtoul(argv[1], NULL, 0);
else value = 0x400;
*--bp = '\0';
while (value > 0) {
*--bp = '0' + (value & 7ul);
value /= 8;
}
printf("Octal = %s\n", bp);
return 0;
}
$ cc -o /tmp/octal /tmp/octal.c
$ /tmp/octal 400
Octal = 620
$ /tmp/octal 1024
Octal = 2000
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-11 06:37 -0700 |
| Message-ID | <86czc2qbfo.fsf@linuxsc.com> |
| In reply to | #167570 |
scott@slp53.sl.home (Scott Lurndal) writes:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> ManyBeers <markzuffi@yahoo.com> writes:
>>
>>> int convertDecimalToOctal(int decimalNumber);
>>
>> The following program tries to convert the number given in main
>> to its octal representation, which is printed to standard output.
>>
>> I wrote it just to the point where it seems to work for this
>> special case, but I'm not convinced that it will print the
>> correct result in all cases or does not overflow any of its
>> buffers!
>>
>> #include <stdio.h>
>> #include <string.h>
>>
>> /* are there digits above 0 in the buffer? */
>> int digits_in( char buffer[] )
>> { size_t i = 0;
>> for( ; i < strlen( buffer )&& buffer[ i ]=='0'; ++i );
>> return buffer[ i ]> '0' && buffer[ i ]<= '9'; }
>>
>> /* write div to "result" and returns the remainder */
>> int divrem
>> ( char dividend[], char result[], int base_of_dividend, int divisor )
>> { { size_t i = 0;
>> for( ; i < strlen( dividend ); ++i )
>> result[ i ]= ' '; result[ i ]= 0; }
>> int r = 0; int j = 0; int k = 0;
>> for( size_t i = 0; i < strlen( dividend ); ++i )
>> { if( dividend[ i ]!= ' ' )
>> { r = r * base_of_dividend + dividend[ i ]- '0';
>> if( r >= divisor )
>> { int const q = r/divisor; r = r%8;
>> result[ j ]=( char )( q + '0' ); }
>> else
>> { result[ j ]='0'; }} ++j; }
>> return r; }
>>
>> /* convert number, which is given in the base_of_dividend into
>> base_of_result */
>> void convert
>> ( char number[], char buffer[],
>> int base_of_dividend,
>> int base_of_result /* must not be larger than base_of_dividend */ )
>> { if( digits_in( number ))
>> { int const digit =
>> divrem( number, buffer, base_of_dividend, base_of_result );
>> { convert( buffer, number, base_of_dividend, base_of_result );
>> putchar( '0' + digit ); }}}
>>
>> int main( void )
>> { /* source in dec */
>> char a[] = "897528309349537459261193475234783479487034102857389475930";
>> /* the buffer must at least have a's len */
>> char b[] = " ";
>> convert( a, b, 10, 8 );
>> putchar( '\n' ); }
>
> Somewhat more concisely:
>
> $ cat /tmp/octal.c
> #include <stdint.h>
> #include <stdio.h>
> #include <string.h>
>
>
> int
> main(int argc, const char **argv, const char **envp)
> {
> char buf[64];
> char *bp = &buf[64];
> uint64_t value;
>
> if (argc > 1) value = strtoul(argv[1], NULL, 0);
> else value = 0x400;
>
> *--bp = '\0';
> while (value > 0) {
> *--bp = '0' + (value & 7ul);
> value /= 8;
> }
>
> printf("Octal = %s\n", bp);
> return 0;
> }
This code concisely solves a very different problem. SR's code
is meant to address the problem of converting values that will
not fit in any of C's standard integer types. This code doesn't
even try to do that.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-11 16:31 +0000 |
| Message-ID | <Q3oTK.407755$iiS8.390510@fx17.iad> |
| In reply to | #167600 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>> ManyBeers <markzuffi@yahoo.com> writes:
>>>
>>>> int convertDecimalToOctal(int decimalNumber);
>>>
>>> The following program tries to convert the number given in main
>>> to its octal representation, which is printed to standard output.
>>>
>>> I wrote it just to the point where it seems to work for this
>>> special case, but I'm not convinced that it will print the
>>> correct result in all cases or does not overflow any of its
>>> buffers!
>>>
>>> #include <stdio.h>
>>> #include <string.h>
>>>
>>> /* are there digits above 0 in the buffer? */
>>> int digits_in( char buffer[] )
>>> { size_t i = 0;
>>> for( ; i < strlen( buffer )&& buffer[ i ]=='0'; ++i );
>>> return buffer[ i ]> '0' && buffer[ i ]<= '9'; }
>>>
>>> /* write div to "result" and returns the remainder */
>>> int divrem
>>> ( char dividend[], char result[], int base_of_dividend, int divisor )
>>> { { size_t i = 0;
>>> for( ; i < strlen( dividend ); ++i )
>>> result[ i ]= ' '; result[ i ]= 0; }
>>> int r = 0; int j = 0; int k = 0;
>>> for( size_t i = 0; i < strlen( dividend ); ++i )
>>> { if( dividend[ i ]!= ' ' )
>>> { r = r * base_of_dividend + dividend[ i ]- '0';
>>> if( r >= divisor )
>>> { int const q = r/divisor; r = r%8;
>>> result[ j ]=( char )( q + '0' ); }
>>> else
>>> { result[ j ]='0'; }} ++j; }
>>> return r; }
>>>
>>> /* convert number, which is given in the base_of_dividend into
>>> base_of_result */
>>> void convert
>>> ( char number[], char buffer[],
>>> int base_of_dividend,
>>> int base_of_result /* must not be larger than base_of_dividend */ )
>>> { if( digits_in( number ))
>>> { int const digit =
>>> divrem( number, buffer, base_of_dividend, base_of_result );
>>> { convert( buffer, number, base_of_dividend, base_of_result );
>>> putchar( '0' + digit ); }}}
>>>
>>> int main( void )
>>> { /* source in dec */
>>> char a[] = "897528309349537459261193475234783479487034102857389475930";
>>> /* the buffer must at least have a's len */
>>> char b[] = " ";
>>> convert( a, b, 10, 8 );
>>> putchar( '\n' ); }
>>
>> Somewhat more concisely:
>>
>> $ cat /tmp/octal.c
>> #include <stdint.h>
>> #include <stdio.h>
>> #include <string.h>
>>
>>
>> int
>> main(int argc, const char **argv, const char **envp)
>> {
>> char buf[64];
>> char *bp = &buf[64];
>> uint64_t value;
>>
>> if (argc > 1) value = strtoul(argv[1], NULL, 0);
>> else value = 0x400;
>>
>> *--bp = '\0';
>> while (value > 0) {
>> *--bp = '0' + (value & 7ul);
>> value /= 8;
>> }
>>
>> printf("Octal = %s\n", bp);
>> return 0;
>> }
>
>This code concisely solves a very different problem. SR's code
>is meant to address the problem of converting values that will
>not fit in any of C's standard integer types. This code doesn't
>even try to do that.
So, replace 'uint64_t' with 'mpz_t'. The rest remains basically unchanged.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-09-13 15:44 -0700 |
| Message-ID | <86k066opxp.fsf@linuxsc.com> |
| In reply to | #167613 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>
>>>> ManyBeers <markzuffi@yahoo.com> writes:
>>>>
>>>>> int convertDecimalToOctal(int decimalNumber);
>>>>
>>>> The following program tries to convert the number given in main
>>>> to its octal representation, which is printed to standard output.
>>>>
>>>> I wrote it just to the point where it seems to work for this
>>>> special case, but I'm not convinced that it will print the
>>>> correct result in all cases or does not overflow any of its
>>>> buffers!
>>>>
>>>> #include <stdio.h>
>>>> #include <string.h>
>>>>
>>>> /* are there digits above 0 in the buffer? */
>>>> int digits_in( char buffer[] )
>>>> { size_t i = 0;
>>>> for( ; i < strlen( buffer )&& buffer[ i ]=='0'; ++i );
>>>> return buffer[ i ]> '0' && buffer[ i ]<= '9'; }
>>>>
>>>> /* write div to "result" and returns the remainder */
>>>> int divrem
>>>> ( char dividend[], char result[], int base_of_dividend, int divisor )
>>>> { { size_t i = 0;
>>>> for( ; i < strlen( dividend ); ++i )
>>>> result[ i ]= ' '; result[ i ]= 0; }
>>>> int r = 0; int j = 0; int k = 0;
>>>> for( size_t i = 0; i < strlen( dividend ); ++i )
>>>> { if( dividend[ i ]!= ' ' )
>>>> { r = r * base_of_dividend + dividend[ i ]- '0';
>>>> if( r >= divisor )
>>>> { int const q = r/divisor; r = r%8;
>>>> result[ j ]=( char )( q + '0' ); }
>>>> else
>>>> { result[ j ]='0'; }} ++j; }
>>>> return r; }
>>>>
>>>> /* convert number, which is given in the base_of_dividend into
>>>> base_of_result */
>>>> void convert
>>>> ( char number[], char buffer[],
>>>> int base_of_dividend,
>>>> int base_of_result /* must not be larger than base_of_dividend */ )
>>>> { if( digits_in( number ))
>>>> { int const digit =
>>>> divrem( number, buffer, base_of_dividend, base_of_result );
>>>> { convert( buffer, number, base_of_dividend, base_of_result );
>>>> putchar( '0' + digit ); }}}
>>>>
>>>> int main( void )
>>>> { /* source in dec */
>>>> char a[] = "897528309349537459261193475234783479487034102857389475930";
>>>> /* the buffer must at least have a's len */
>>>> char b[] = " ";
>>>> convert( a, b, 10, 8 );
>>>> putchar( '\n' ); }
>>>
>>> Somewhat more concisely:
>>>
>>> $ cat /tmp/octal.c
>>> #include <stdint.h>
>>> #include <stdio.h>
>>> #include <string.h>
>>>
>>>
>>> int
>>> main(int argc, const char **argv, const char **envp)
>>> {
>>> char buf[64];
>>> char *bp = &buf[64];
>>> uint64_t value;
>>>
>>> if (argc > 1) value = strtoul(argv[1], NULL, 0);
>>> else value = 0x400;
>>>
>>> *--bp = '\0';
>>> while (value > 0) {
>>> *--bp = '0' + (value & 7ul);
>>> value /= 8;
>>> }
>>>
>>> printf("Octal = %s\n", bp);
>>> return 0;
>>> }
>>
>> This code concisely solves a very different problem. SR's code
>> is meant to address the problem of converting values that will
>> not fit in any of C's standard integer types. This code doesn't
>> even try to do that.
>
> So, replace 'uint64_t' with 'mpz_t'. The rest remains basically
> unchanged.
And that is a solution to yet a different problem. Stefan Ram is
showing how to accomplish the conversion without relying on any
special libraries. The code he gave has value for people who
want to understand the nature of (one way to accomplish) the
conversion. Your suggestion throws away that value.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web