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:
(295600127)
#include <stdio.h>
#include <math.h>

int convertDecimalToOctal(int decimalNumber);
int main()
{ int decimalNumber;

printf("Enter a decimal number: ");
scanf("%d", &decimalNumber);

printf("%d in decimal = %d in octal", decimalNumber, convertDecimalToOctal(decimalNumber));

return 0;
}

int convertDecimalToOctal(int decimalNumber)
{ int octalNumber = 0, i = 1;

while (decimalNumber != 0)
{
octalNumber += (decimalNumber % 8) * i;
decimalNumber /= 8;
i *= 10;
}

return octalNumber;
} As you can see I posted it has limit of 295600127. why is that.
but what I really want is could somebody explain exactly what
the code is doing below the 1st... return 0;.... which I think is the
int convertDecimaltoOctal(int decimalNumber)function and it's
implementation.
I want to fix the program so it will do at least a full 32bitnumber (4294967295)
So here octalNumber += (decimalNumber % 8) * i;s how I see it: the code defined 2 variables octalnumber=0
and i=1 then it goes into a whileloop ...while decimalNumber is not 0...
do this:
octalNumber += (decimalNumber % 8) * i; modulus the decNum(say 1000) multiply that by i (which equals 1 for now) increment and then assign to
octNum? The doing something and then assigning is tricky. Anyways if you know how could you explain exactly what the function does and in which order.
This is my own oct/dec converter:
/*decimal_octal_converter*/

#include <stdio.h>
/*---------------*/

unsigned int dec, oct;

int main(void)

{
printf("Enter a number between 0 and 4294967295: ");
scanf ("%d", &dec);

printf("Octal value: %d%d%d%d%d%d%d%d%d%d%d",
dec/(8*8*8*8*8*8*8*8*8*8),
dec%(8*8*8*8*8*8*8*8*8*8)/(8*8*8*8*8*8*8*8*8),
dec%(8*8*8*8*8*8*8*8*8)/(8*8*8*8*8*8*8*8),
dec%(8*8*8*8*8*8*8*8)/(8*8*8*8*8*8*8),
dec%(8*8*8*8*8*8*8)/(8*8*8*8*8*8),
dec%(8*8*8*8*8*8)/(8*8*8*8*8),
dec%(8*8*8*8*8)/(8*8*8*8),
dec%(8*8*8*8)/(8*8*8),
dec%(8*8*8)/(8*8),
dec%(8*8*8)%(8*8)/8, dec%8);

return 0;
}
it is the only way I could figure out how to do it.

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:
> (295600127)
> #include <stdio.h>
> #include <math.h>
>
> int convertDecimalToOctal(int decimalNumber);
> int main()
> {
> int decimalNumber;
>
> printf("Enter a decimal number: ");
> scanf("%d", &decimalNumber);
>
> printf("%d in decimal = %d in octal", decimalNumber, convertDecimalToOctal(decimalNumber));
>
> return 0;
> }
>
> int convertDecimalToOctal(int decimalNumber)
> {
> int octalNumber = 0, i = 1;
>
> while (decimalNumber != 0)
> {
> octalNumber += (decimalNumber % 8) * i;
> decimalNumber /= 8;
> i *= 10;
> }
>
> return octalNumber;
> }

The `#include <math.h>` is unnecessary. The program doesn't use any
functions that are declared in that header.

The program does a very strange kind of conversion. Integers are stored
in *binary*, and may be *displayed* in decimal, octal, or hexadecimal
(or any other base if you write the code to do it).

This convertDecimalToOctal function takes an integer argument (which,
again, is represented in binary) and returns an integer whose decimal
representation is the same as the octal representation of the argument.

In general, that's really not a useful thing to do. The resulting value
is not meaningful.

Decimal and octal representations are *strings*, not integers. Take a
look at the printf call in main():

printf("%d in decimal = %d in octal", decimalNumber, convertDecimalToOctal(decimalNumber));

The 'd' in "%d" stands for "decimal".

A more useful thing to do is to create a *string" containing the octal
representation of the argument. And printf's "%o" format already does
exactly that. You can use sprintf or snprintf to store the result in a
string.

Or you can write your own function to generate an octal string.
(Returning strings from C functions is tricky. See
https://www.c-faq.com/ .)

> As you can see I posted it has limit of 295600127. why is that.

int is apparently 32 bits on your system (that's very common). The
maximum 32-bit signed integer value is 2147483647.

The function returns 2147477777 for an argument of 295600127. That's
very close to the maximum 32-bit signed integer value, which is 2**31-1
or 2147483647.

[...]

--
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 */

ManyBeers <markzuffi@yahoo.com> writes:

> Hello I am teaching myself C and I need some help with a problem.

I think (though I am not sure) that you are also teaching yourself
programming at the same time. That makes it hard. First, because most
of the problems will to do with how you write code -- any code -- but
your be fooled into thinking the problem is you don't know C. Second, C
is a rather fussy language for a beginner to learn. It's small (that's
good) but it is full of odd corners. Third, there are a boat load of
very bad tutorials out there that use C. Don't know why, but the
language seems to attract them.

> After a search for dec/oct convert I found this code:
> (295600127)
> #include <stdio.h>
> #include <math.h>
>
> int convertDecimalToOctal(int decimalNumber);
> int main()
> {
> int decimalNumber;

The number is just a number. It's not decimal and it's not octal. It
may be binary inside the machine, but C lets you treat it like a number.

> printf("Enter a decimal number: ");

This message is OK because you are asking for a number to entered using
decimal digits.

> scanf("%d", &decimalNumber);

Always check that input has been successful. It's one of the most
important habits to get into.

> printf("%d in decimal = %d in octal", decimalNumber, convertDecimalToOctal(decimalNumber));
>
> return 0;
> }

printf can do what you want:

int main(void)
{ int number;
printf("Enter a decimal number: ");
if (scanf("%d", &number) == 1)
printf("%d in decimal = %d in octal = %o\n", number, (unsigned)number);
return 0;
}

And here we hit one of C's corners. The %o format expected an unsigned
int.

> int convertDecimalToOctal(int decimalNumber)
> {
> int octalNumber = 0, i = 1;
>
> while (decimalNumber != 0)
> {
> octalNumber += (decimalNumber % 8) * i;
> decimalNumber /= 8;
> i *= 10;
> }
>
> return octalNumber;
> }

This is weird. Decimal and octal are about representations so one would
expect a function like this generate a string of digits. What this is
doing is computing a number (note neither decimal nor octal, just a
number) that when printed as a decimal, shows the octal digits that
correspond to the original number.

This is a bad idea for all sorts of reasons. I'll go into them if you
want to know, but it's best to forget you ever saw this function!

> As you can see I posted it has limit of 295600127. why is that.

That's one of the problems. The number which, when printed as a
decimal, shows the digits of the original in octal has to be bigger than
than the original.

> but what I really want is could somebody explain exactly what
> the code is doing below the 1st... return 0;.... which I think is the
> int convertDecimaltoOctal(int decimalNumber)function and it's
> implementation.
> I want to fix the program so it will do at least a full 32bitnumber (4294967295)
> So here octalNumber += (decimalNumber % 8) * i;s how I see it: the code defined 2 variables octalnumber=0
> and i=1 then it goes into a whileloop ...while decimalNumber is not 0...
> do this:
> octalNumber += (decimalNumber % 8) * i; modulus the decNum(say 1000) multiply that by i (which equals 1 for now) increment and then assign to
> octNum? The doing something and then assigning is tricky. Anyways if
> you know how could you explain exactly what the function does and in
> which order.

Ditch the whole idea of this function. Decimal and octal are about
representations as strings of digits. If you don't want to use %o, the
function you need should write digits into a string buffer:

void octal_digits(int n, char *buf, size_t len);

You could, of course, return an allocated string, but already you are
hitting C issues that have nothing to do with programming.

> This is my own oct/dec converter:
> /*decimal_octal_converter*/
>
> #include <stdio.h>
> /*---------------*/
>
> unsigned int dec, oct;
>
> int main(void)
>
> {
> printf("Enter a number between 0 and 4294967295: ");
> scanf ("%d", &dec);
>
>
> printf("Octal value: %d%d%d%d%d%d%d%d%d%d%d",
> dec/(8*8*8*8*8*8*8*8*8*8),
> dec%(8*8*8*8*8*8*8*8*8*8)/(8*8*8*8*8*8*8*8*8),
> dec%(8*8*8*8*8*8*8*8*8)/(8*8*8*8*8*8*8*8),
> dec%(8*8*8*8*8*8*8*8)/(8*8*8*8*8*8*8),
> dec%(8*8*8*8*8*8*8)/(8*8*8*8*8*8),
> dec%(8*8*8*8*8*8)/(8*8*8*8*8),
> dec%(8*8*8*8*8)/(8*8*8*8),
> dec%(8*8*8*8)/(8*8*8),
> dec%(8*8*8)/(8*8),
> dec%(8*8*8)%(8*8)/8, dec%8);
>
> return 0;
> }
> it is the only way I could figure out how to do it.

You need exercises to learn about recursive functions and/or loops.
What resources are you using to learn?

--
Ben.

On Thu, 8 Sep 2022 11:34:04 -0700 (PDT), ManyBeers
<markzuffi@yahoo.com> wrote:

>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:
>(295600127)
>#include <stdio.h>
>#include <math.h>
>
>int convertDecimalToOctal(int decimalNumber);
>int main()
>{
> int decimalNumber;
>
> printf("Enter a decimal number: ");
> scanf("%d", &decimalNumber);
>
> printf("%d in decimal = %d in octal", decimalNumber, convertDecimalToOctal(decimalNumber));
>
> return 0;
>}
>
>int convertDecimalToOctal(int decimalNumber)
>{
> int octalNumber = 0, i = 1;
>
> while (decimalNumber != 0)
> {
> octalNumber += (decimalNumber % 8) * i;
> decimalNumber /= 8;
> i *= 10;
> }
>
> return octalNumber;
>}
>As you can see I posted it has limit of 295600127. why is that.

The program is storing the octal value in an int, not in a string of
characters that happen to be in range of 0 to 7. The octal value of
295600127 is 02147477777. Adding 1 to this value yields 02147500000
which is a perfectly valid string of characters. However, the decimal
value 2147500000 is too large to be expressed as a 32-bit signed int.

> but what I really want is could somebody explain exactly what
>the code is doing below the 1st... return 0;.... which I think is the
>int convertDecimaltoOctal(int decimalNumber)function and it's
>implementation.

Yes, that is exactly what it is. Take a piece of paper and play
computer. Pick a modest size initial value for decimalNumber and
compute the values of all the variables until the loop terminates.
Also read the Wikipedia article on the octal base numbering system.

>I want to fix the program so it will do at least a full 32bitnumber (4294967295)

The maximum 32 bit number has 9 decimal digits. The octal
representation has at least 10 octal digits. Since the function
treats the octal digits as decimal digits, you cannot fit 10 of them
in a 32 bit int.

There are at least two ways to do what you want:
1 - Change the function to use long long int instead of int.
2 - Change the function to store the octal digits as characters in
an array of characters.

Both options require changes to areas outside the function also.

<snip>

--
Remove del for email

This is a not-uncommon algorithm for performing decimal to octal
conversions by hand: it will convert a decimal number (like 20) to a
string of digits that is that looks like the same value in octal
(there's a lot of handwaving going on in that description). So if you
give it 20, it will give you back 24.

As others have pointed out, doing a straight transliteration of that
by-hand algorithm to C is really sort of nonsensical, because the number
you're looking at is really in the machine's binary internal storage
representation.

As for what it's doing... the basic idea is that the modulus
operator is being used to grab the rightmost octal digit from your
input, and then the multiplication by i (which is a power of ten) puts
it at the left end of the number you're creating. Dividing the input by
8 is getting rid of the least significant octal digit.

So look at an input of 20

20 % 8 is 4, so we've got the least significant digit.
20 / 8 is 2, so that's what we've got left from our input.

2 % 8 is 2; multiply that by ten and add to get 24
2 / 8 is 0, so we're done.

Input 20, output 24. 24 is a decimal number that has the same digits as
if it were the octal representation of 20.

But the best advice I can give: find another source for your coding
examples.

On Thursday, 8 September 2022 at 21:34:12 UTC+3, ManyBeers wrote:
> 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:

You are deeply confused yourself and so are using confusing example.
The octal, decimal, hexadecimal and binary are textual representations
of number.

The int in C is however binary, not textual. It is always signed, always
required to consist of bytes and on vast majority of platforms it consists
of 4 bytes of 8 bits (so 32 bits) in two's complement representation in
little-endian order of bytes, but C standard is not requiring that.

So if you want to achieve that the binary bits of your type are laid out in
some different manner than these are in int on platform that you use
then you need to specify how. Bit-by-bit. Dim words "octal" and "decimal"
are from entirely other universe, from universe of texts.

In article <d52d6c72-0ec1-49a5-a2c0-7a00b3f357fan@googlegroups.com>,
Tiib <ootiib@hot.ee> wrote:
>On Thursday, 8 September 2022 at 21:34:12 UTC+3, ManyBeers wrote:
>> 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:
>
>You are deeply confused yourself and so are using confusing example.
>The octal, decimal, hexadecimal and binary are textual representations
>of number.
>
>The int in C is however binary, not textual. It is always signed, always
>required to consist of bytes and on vast majority of platforms it consists
>of 4 bytes of 8 bits (so 32 bits) in two's complement representation in
>little-endian order of bytes, but C standard is not requiring that.
>
>So if you want to achieve that the binary bits of your type are laid out
>in some different manner than these are in int on platform that you use
>then you need to specify how. Bit-by-bit. Dim words "octal" and "decimal"
>are from entirely other universe, from universe of texts.

I love this post! So lyrical. So Shakespearian.

So other-worldly.

--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

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;

Next we need to talk about what you're doing, which is base
conversion. That is to say, you have a number in one base, and
you want to convert it to a different base. Properly speaking
the word digit usually means a decimal digit, or a value between
0 and 9 inclusive. However, we are working in various bases, so
I will use "digit" to mean a value in the appropriate range for
the base in question. Now, what is a number in base B? It is a
sequence of "digits" in base B, that is, values between 0 and
B-1. A natural way to represent a number in base B is as an
array of elements for the "digits", where each element can hold a
value in the relevant range. For bases up to 256, these elements
can be of type UC - an unsigned character can hold all values
between 0 and 255, so it can hold all values between 0 and 9 (for
decimal), or all values between 0 and 7 (for octal), or all
values between 0 and 15 (for hexadecimal), etc. Here are some
sample holders of numbers in different bases:

UC decimal_197[] = { 1, 9, 7 };
UC octal_1777[] = { 1, 7, 7, 7 };
UC hex_FF[] = { 15, 15 };

(Slight digression: Notice that there is nothing marking the
"end" of a number. To use these variables we need to know how
many "digits" are held, which is the same as the number of
elements in each array. There is a well-known idiom in C that
computes what this is, given the variable name. That idiom is
typically written as a macro, as for example

#define NUMBER_OF( a ) (sizeof (a) / sizeof *(a))

We will see uses of this macro in the code below.)

Okay, so we have some array variables holding numbers in
different bases. To make use of these numbers we need to convert
them into C's native numeric type, which here means the type UI.
What is a value of type UI? Because a UI has 32 bits, a variable
of type UI is a single "digit" in base 2**32, or 4294967296.
Here is a function to convert a base-10 number to a UI, which is
to say to a base-4294967296 number:

UI
base_10_to_base_4294967296( UC digits[], unsigned n ){
unsigned i;
UI r = 0;
for( i = 0; i < n; i++ ){
r = r * 10 + digits[i];
}
return r;
}

Code to convert a base-8 number to a UI is almost identical:

UI
base_8_to_base_4294967296( UC digits[], unsigned n ){
unsigned i;
UI r = 0;
for( i = 0; i < n; i++ ){
r = r * 8 + digits[i];
}
return r;
}

And it's easy to see how to generalize these functions into a
single function that will handle any base between 2 and 256:

UI
base_b_to_base_4294967296( unsigned b, UC digits[], unsigned n ){
unsigned i;
UI r = 0;
for( i = 0; i < n; i++ ){
r = r * b + digits[i];
}
return r;
}

Having written these, we are now ready to write a simple test
driver:

#include <stdio.h>

#define NUMBER_OF( a ) (sizeof (a) / sizeof *(a))

int
main(){
UC decimal_197[] = { 1, 9, 7 };
UC octal_1777[] = { 1, 7, 7, 7 };
UC hex_FF[] = { 15, 15 };

unsigned decimal_197_digits = NUMBER_OF( decimal_197 );
unsigned octal_1777_digits = NUMBER_OF( octal_1777 );
unsigned hex_FF_digits = NUMBER_OF( hex_FF );

UI u197d = base_10_to_base_4294967296( decimal_197, decimal_197_digits );
UI u1777o = base_8_to_base_4294967296( octal_1777, octal_1777_digits );
UI uFFh = base_b_to_base_4294967296( 16, hex_FF, hex_FF_digits );

printf( " u197d is %7u decimal\n", u197d );
printf( "u1777o is %7u decimal\n", u1777o );
printf( " uFFh is %7u decimal\n", uFFh );
printf( "\n" );

printf( " u197d is %7o octal\n", u197d );
printf( "u1777o is %7o octal\n", u1777o );
printf( " uFFh is %7o octal\n", uFFh );
printf( "\n" );

printf( " u197d is %7x hexidecimal\n", u197d );
printf( "u1777o is %7x hexidecimal\n", u1777o );
printf( " uFFh is %7x hexidecimal\n", uFFh );
printf( "\n" );

return 0;
}

Notice that the UI variables are not inherently either decimal,
octal, or hexadecimal. The printed values come out as decimal,
octal, or hexadecimal, by virtue of what conversion specifier
(u, o, or x) is used in the printf() format string. You see
that?

Now for the next step. The code above allows conversion from an
arbitrary base (up to 256) to the base of C's native unsigned
type. What we're looking for is a function that goes the other
direction: from the base of C's native unsigned type to an array
of "digits" in a smaller base. This function needs different
interface. In particular, it should take a parameter that is a
pointer to an array of UC, and should return a count of the
number of digits in the result. Here is our first try:

unsigned
base_4294967296_to_base_b_X( UI value, unsigned b, UC out[] ){
UI v = value;
unsigned k = 0;

do {
out[k] = v % b;
k++;
} while( v /= b, v != 0 );

return k;
}

This function sort of works, but it has a problem: the generated
"digits" are backwards! An annoying artifact of conversions like
this is they really want to start at "the wrong end".

There are various ways to correct this problem, but probably the
easiest to explain is to put digits into a temporary array, and
then copy them in reverse order to the out[] array. And so,

unsigned
base_4294967296_to_base_b( UI value, unsigned b, UC out[] ){
UI v = value;
unsigned k = 0;
UC digits[100];
unsigned i;

do {
digits[k] = v % b;
k++;
} while( v /= b, v != 0 );

for( i = 0; i < k; i++ ){
out[ i ] = digits[ k-1-i ];
}

return k;
}

Please take a look over the above code and explanations, and see
if things make more sense now. Are there any questions you have?

One more note, on a more advanced topic. In the code above we
have limited the base-4294967296 numbers to only one UI, which is
to say limited those numbers to only one "digit". If we want to
represent very large numbers, we can have an _array_ of UI, with
each element of the array holding a single base-4294967296 digit.
Doing that is possible of course, but it's a lot harder, so while
you're still learning C you might want to stick with the simpler
cases explained above.

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.

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' ); }

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

On 09/09/2022 21:06, Scott Lurndal wrote:
> 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.

And those type names are better in a number of ways. They are clearer,
more precise, and hide the design flaw in C of mixing the concepts of
"character" and "small number". In particular, they specify exactly
what size your numbers are, rather that having hidden assumptions in the
code.

The rest of Tim's post goes downhill rapidly from there. When you need
a calculator to figure out the name of your functions, you have /really/
got things wrong.

On 10/09/2022 10:58, David Brown wrote:
> On 09/09/2022 21:06, Scott Lurndal wrote:
>> 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.
>
> And those type names are better in a number of ways.  They are clearer,
> more precise, and hide the design flaw in C

(What, C has design flaws?)

> of mixing the concepts of
> "character" and "small number".  In particular, they specify exactly
> what size your numbers are, rather that having hidden assumptions in the
> code.

I don't care for UC and UI, but I dislike those uint8_t forms so much
that when writing any C code, I much prefer to type:

typedef long long int i64;
typedef unsigned char byte;

then using the more succinct 'i64/byte', than having to write
'int64_t/'uint8_8' in 100 different places. (That was an actual typo; I
left it in to help explain why.)

I don't even want to write them once using this:

#include <stdint.h>
typedef int64_t i64;
typedef uint8_t byte;

> The rest of Tim's post goes downhill rapidly from there.  When you need
> a calculator to figure out the name of your functions, you have /really/
> got things wrong.

Yeah, you just don't hardcode just constants at multiple places in the code.

One of my programs uses base-1000000000, but you won't see it as a
function name, it is defined once at the top.

On 10/09/2022 12:37, Bart wrote:
> On 10/09/2022 10:58, David Brown wrote:
>> On 09/09/2022 21:06, Scott Lurndal wrote:
>>> 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.
>>
>> And those type names are better in a number of ways.  They are
>> clearer, more precise, and hide the design flaw in C
>
> (What, C has design flaws?)

Yes, haven't you noticed? :-) It's inevitable, of course, given the
difficulty they had in the 1970's of predicting the next 50 years of the
computing world.

>
>> of mixing the concepts of "character" and "small number".  In
>> particular, they specify exactly what size your numbers are, rather
>> that having hidden assumptions in the code.
>
> I don't care for UC and UI, but I dislike those uint8_t forms so much
> that when writing any C code, I much prefer to type:
>
>     typedef long long int i64;
>     typedef unsigned char byte;

I don't think a re-hash of this discussion helps anyone. Suffice to say
that whatever you may think of the standard names for fixed size integer
types, the fact that they are standard goes a very long way to trumping
any alternative name for the same purpose - especially for a beginner.
(However, your choices would be much better than Tim's.)

>
>> The rest of Tim's post goes downhill rapidly from there.  When you
>> need a calculator to figure out the name of your functions, you have
>> /really/ got things wrong.
>
> Yeah, you just don't hardcode just constants at multiple places in the
> code.
> > One of my programs uses base-1000000000, but you won't see it as a
> function name, it is defined once at the top.

David Brown <david.brown@hesbynett.no> writes:

> On 09/09/2022 21:06, Scott Lurndal wrote:
>> 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.
>
> And those type names are better in a number of ways. They are
> clearer, more precise, and hide the design flaw in C of mixing the
> concepts of "character" and "small number". In particular, they
> specify exactly what size your numbers are, rather that having hidden
> assumptions in the code.

But they both say too much. The 'source' integer size need not be 32
bits and, given that there are no other obvious requirements, unsigned
int seems to me to be the natural choice. And if the requirements were
that 32-bit numbers could be handled, uint_least32_t (or uint_fast32_t)
more precisely meets the need.

And the uint8_t is also unnecessarily specific. We do want to know that
digits up to 255 can be stored, but nothing goes wrong if the type is
wider. uint_least8_t says exactly what's wanted and no more.

Mind you, since char is guaranteed to be at least 8 bits wide, unsigned
char is effectively uint_least8_t.

--
Ben.

On 10/09/2022 13:54, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 09/09/2022 21:06, Scott Lurndal wrote:
>>> 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.
>>
>> And those type names are better in a number of ways. They are
>> clearer, more precise, and hide the design flaw in C of mixing the
>> concepts of "character" and "small number". In particular, they
>> specify exactly what size your numbers are, rather that having hidden
>> assumptions in the code.
>
> But they both say too much. The 'source' integer size need not be 32
> bits and, given that there are no other obvious requirements, unsigned
> int seems to me to be the natural choice. And if the requirements were
> that 32-bit numbers could be handled, uint_least32_t (or uint_fast32_t)
> more precisely meets the need.

"unsigned int" might have been a reasonable choice, but Tim's code goes
on to rely on it being 32-bit. (Or to be more accurate, it /says/ it
relies on it being 32-bit.)

>
> And the uint8_t is also unnecessarily specific. We do want to know that
> digits up to 255 can be stored, but nothing goes wrong if the type is
> wider. uint_least8_t says exactly what's wanted and no more.
>
> Mind you, since char is guaranteed to be at least 8 bits wide, unsigned
> char is effectively uint_least8_t.
>

There is such a thing as being /too/ portable. 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. You are,
of course, technically correct in everything you write here - but that
still does not make these types a better choice in the circumstances.
(Again, all in my humble opinion.)

An alternative approach would be to have typedefs that are descriptive
and application-specific, and which can be changed later to allow
different sizes to be converted. Especially in light of it being code
for someone relatively unfamiliar with the language, I'd err on the side
of longer names (and certainly not cryptic short abbreviations that are
not particularly relevant to the usage) :

typedef uint8_t digit_type;
typedef uint32_t number_type;

and perhaps :

static const number_type max_number = -1;

if it is needed in the code later.

I'd be quite happy with "unsigned char" and "unsigned int" for these
typedefs, if that is the programmer's preference. But I certainly would
not want the number 4294967296 as part of the function names!

Bart <bc@freeuk.com> writes:
>On 10/09/2022 10:58, David Brown wrote:
>> On 09/09/2022 21:06, Scott Lurndal wrote:
>>> 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.
>>
>> And those type names are better in a number of ways.  They are clearer,
>> more precise, and hide the design flaw in C
>
>(What, C has design flaws?)
>
>> of mixing the concepts of
>> "character" and "small number".  In particular, they specify exactly
>> what size your numbers are, rather that having hidden assumptions in the
>> code.
>
>I don't care for UC and UI, but I dislike those uint8_t forms so much
>that when writing any C code, I much prefer to type:
>
> typedef long long int i64;
> typedef unsigned char byte;

That's fine when nobody else has to ever work on your source code.

Otherwise, use the standard types.

On 10/09/2022 15:42, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:

>> I don't care for UC and UI, but I dislike those uint8_t forms so much
>> that when writing any C code, I much prefer to type:
>>
>> typedef long long int i64;
>> typedef unsigned char byte;
>
> That's fine when nobody else has to ever work on your source code.
>
> Otherwise, use the standard types.

Every other C library and application I used to look at defined its own
types. Even 20 years after C99.

Eg, SDL, GTK, OpenGL use Uint or GLint or Gluint.

SQLite uses sqlite_uint32.

BZip uses UInt32.

STB_image uses stbi__uint32, etc.

On reason might have been in case stdint.h was not available. But I also
believe the uint32_t style is unliked.

In either case, there is still a huge amount of C code about that
doesn't use those standard types.

On 10/09/2022 17:10, Bart wrote:
> On 10/09/2022 15:42, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> I don't care for UC and UI, but I dislike those uint8_t forms so much
>>> that when writing any C code, I much prefer to type:
>>>
>>>      typedef long long int i64;
>>>      typedef unsigned char byte;
>>
>> That's fine when nobody else has to ever work on your source code.
>>
>> Otherwise, use the standard types.
>
> Every other C library and application I used to look at defined its own
> types. Even 20 years after C99.
>
> Eg, SDL, GTK, OpenGL use Uint or GLint or Gluint.
>
> SQLite uses sqlite_uint32.
>
> BZip uses UInt32.
>
> STB_image uses stbi__uint32, etc.
>
> On reason might have been in case stdint.h was not available. But I also
> believe the uint32_t style is unliked.
>

It might well be the case that some people (other than you) dislike the
style "uint32_t". But you can be very sure that nobody uses
"sqlite_uint32" because they think it is neater or more convenient than
"uint32_t".

We may be 20 years after C99, but it took about 10 years for it to
become commonly supported and used. It's only just recently that the
Linux kernel has moved to a standard newer than C90 (plus gcc extensions).

> In either case, there is still a huge amount of C code about that
> doesn't use those standard types.

Yes. That doesn't mean it is remotely a good idea to make things worse
by adding your own versions that don't even have the advantage of being
sure there are no likely conflicts with other people's versions.

Remember, whether you like it or not - and many people, including me,
don't particularly like it - in an implementation with 32-bit "long",
you could choose either "int" or "long" for your "int32_t" type, and
they would be incompatible. So for libraries that had to work with
pre-C99 implementations, their best choice was library-specific sized
integer types. For code that can rely on at least C99 - that is, most C
code written today - anything other than the <stdint.h> types would be a
terrible idea.

It would have been far better if the <stdint.h> types had been
standardised from K&R days, but that ship has sailed long ago.

David Brown <david.brown@hesbynett.no> writes:

> On 10/09/2022 13:54, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 09/09/2022 21:06, Scott Lurndal wrote:
>>>> 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.
>>>
>>> And those type names are better in a number of ways. They are
>>> clearer, more precise, and hide the design flaw in C of mixing the
>>> concepts of "character" and "small number". In particular, they
>>> specify exactly what size your numbers are, rather that having hidden
>>> assumptions in the code.
>> But they both say too much. The 'source' integer size need not be 32
>> bits and, given that there are no other obvious requirements, unsigned
>> int seems to me to be the natural choice. And if the requirements were
>> that 32-bit numbers could be handled, uint_least32_t (or uint_fast32_t)
>> more precisely meets the need.
>
> "unsigned int" might have been a reasonable choice, but Tim's code
> goes on to rely on it being 32-bit. (Or to be more accurate, it
> /says/ it relies on it being 32-bit.)
>
>> And the uint8_t is also unnecessarily specific. We do want to know that
>> digits up to 255 can be stored, but nothing goes wrong if the type is
>> wider. uint_least8_t says exactly what's wanted and no more.
>> Mind you, since char is guaranteed to be at least 8 bits wide, unsigned
>> char is effectively uint_least8_t.
>>
>
> There is such a thing as being /too/ portable.

I was not talking about portability. It's handy when types say what's
needed and what isn't. uint8_t says too much. uint_least8_t is better
because it says exactly what's needed and what isn't. The suggestion
had nothing to do with portability.

> 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.

> You are, of course, technically correct
> in everything you write here - but that still does not make these
> types a better choice in the circumstances. (Again, all in my humble
> opinion.)
>
> An alternative approach would be to have typedefs that are descriptive
> and application-specific, and which can be changed later to allow
> different sizes to be converted. Especially in light of it being code
> for someone relatively unfamiliar with the language, I'd err on the
> side of longer names (and certainly not cryptic short abbreviations
> that are not particularly relevant to the usage) :
>
> typedef uint8_t digit_type;
> typedef uint32_t number_type;

But then why not use the more accurate last8 (and least32) types? They
"complicate" just two lines of code and the verbosity criticism
vanishes.

--
Ben.

On 10/09/2022 19:03, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 10/09/2022 13:54, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 09/09/2022 21:06, Scott Lurndal wrote:
>>>>> 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.
>>>>
>>>> And those type names are better in a number of ways. They are
>>>> clearer, more precise, and hide the design flaw in C of mixing the
>>>> concepts of "character" and "small number". In particular, they
>>>> specify exactly what size your numbers are, rather that having hidden
>>>> assumptions in the code.
>>> But they both say too much. The 'source' integer size need not be 32
>>> bits and, given that there are no other obvious requirements, unsigned
>>> int seems to me to be the natural choice. And if the requirements were
>>> that 32-bit numbers could be handled, uint_least32_t (or uint_fast32_t)
>>> more precisely meets the need.
>>
>> "unsigned int" might have been a reasonable choice, but Tim's code
>> goes on to rely on it being 32-bit. (Or to be more accurate, it
>> /says/ it relies on it being 32-bit.)
>>
>>> And the uint8_t is also unnecessarily specific. We do want to know that
>>> digits up to 255 can be stored, but nothing goes wrong if the type is
>>> wider. uint_least8_t says exactly what's wanted and no more.
>>> Mind you, since char is guaranteed to be at least 8 bits wide, unsigned
>>> char is effectively uint_least8_t.
>>>
>>
>> There is such a thing as being /too/ portable.
>
> I was not talking about portability. It's handy when types say what's
> needed and what isn't. uint8_t says too much. uint_least8_t is better
> because it says exactly what's needed and what isn't. The suggestion
> had nothing to do with portability.

Surely uint_least8_t specifies even more?

That's not a type I've come across anywhere else. And I'd be interested
in which machine it would map to anything other than 'unsigned char' (as
it does on x64.

I can sort of see the use-case, but it sounds niche: you need a u8 type
but don't want to commit to exactly u8 because on some unusual
architecture you don't want it to jump through hoops to give you u8,
when u16 would do just as well. But specifying u16 anyway would be
wasteful everywhere else.

And then there's uint_fast8_t; I can't even make a guess at that. All I
knows is that the last thing I want to see in source code is
uint_least8_t and uint_fast8_t (maybe 'const' too!) cluttering things up
and obscuring the underlying code. uint8_t is bad enough.

I want to see something like 'byte' or 'u8'. For the unusual situation
above, deal with that in usercode via a special usertype.

Bart <bc@freeuk.com> writes:

> On 10/09/2022 19:03, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 10/09/2022 13:54, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 09/09/2022 21:06, Scott Lurndal wrote:
>>>>>> 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.
>>>>>
>>>>> And those type names are better in a number of ways. They are
>>>>> clearer, more precise, and hide the design flaw in C of mixing the
>>>>> concepts of "character" and "small number". In particular, they
>>>>> specify exactly what size your numbers are, rather that having hidden
>>>>> assumptions in the code.
>>>> But they both say too much. The 'source' integer size need not be 32
>>>> bits and, given that there are no other obvious requirements, unsigned
>>>> int seems to me to be the natural choice. And if the requirements were
>>>> that 32-bit numbers could be handled, uint_least32_t (or uint_fast32_t)
>>>> more precisely meets the need.
>>>
>>> "unsigned int" might have been a reasonable choice, but Tim's code
>>> goes on to rely on it being 32-bit. (Or to be more accurate, it
>>> /says/ it relies on it being 32-bit.)
>>>
>>>> And the uint8_t is also unnecessarily specific. We do want to know that
>>>> digits up to 255 can be stored, but nothing goes wrong if the type is
>>>> wider. uint_least8_t says exactly what's wanted and no more.
>>>> Mind you, since char is guaranteed to be at least 8 bits wide, unsigned
>>>> char is effectively uint_least8_t.
>>>>
>>>
>>> There is such a thing as being /too/ portable.
>> I was not talking about portability. It's handy when types say what's
>> needed and what isn't. uint8_t says too much. uint_least8_t is better
>> because it says exactly what's needed and what isn't. The suggestion
>> had nothing to do with portability.
>
> Surely uint_least8_t specifies even more?

The depends on what you mean by specifies more. Yes, it specifies what
you need and what you don't need, so in some sense more than uint8_t.
But uint8_t specifies a more restricted type.

Anyway, I don't like arguing about words. What matters is that uint8_t
is not, logically, what's wanted here.

> That's not a type I've come across anywhere else.

It should be used more widely. I suspect that some programmers
gravitate to the exact width types because they map to how they think
about machines. Others gravitate towards the leastN types because they
map to how they think about algorithms.

> I can sort of see the use-case, but it sounds niche: you need a u8
> type but don't want to commit to exactly u8 because on some unusual
> architecture you don't want it to jump through hoops to give you u8,
> when u16 would do just as well. But specifying u16 anyway would be
> wasteful everywhere else.

You are in the first camp above. The use-case I see is simply
documenting as accurately as possible what the code is doing.

--
Ben.

On 10/09/2022 20:30, Bart wrote:
> On 10/09/2022 19:03, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 10/09/2022 13:54, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 09/09/2022 21:06, Scott Lurndal wrote:
>>>>>> 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.
>>>>>
>>>>> And those type names are better in a number of ways.  They are
>>>>> clearer, more precise, and hide the design flaw in C of mixing the
>>>>> concepts of "character" and "small number".  In particular, they
>>>>> specify exactly what size your numbers are, rather that having hidden
>>>>> assumptions in the code.
>>>> But they both say too much.  The 'source' integer size need not be 32
>>>> bits and, given that there are no other obvious requirements, unsigned
>>>> int seems to me to be the natural choice.  And if the requirements were
>>>> that 32-bit numbers could be handled, uint_least32_t (or uint_fast32_t)
>>>> more precisely meets the need.
>>>
>>> "unsigned int" might have been a reasonable choice, but Tim's code
>>> goes on to rely on it being 32-bit.  (Or to be more accurate, it
>>> /says/ it relies on it being 32-bit.)
>>>
>>>> And the uint8_t is also unnecessarily specific.  We do want to know
>>>> that
>>>> digits up to 255 can be stored, but nothing goes wrong if the type is
>>>> wider.  uint_least8_t says exactly what's wanted and no more.
>>>> Mind you, since char is guaranteed to be at least 8 bits wide, unsigned
>>>> char is effectively uint_least8_t.
>>>>
>>>
>>> There is such a thing as being /too/ portable.
>>
>> I was not talking about portability.  It's handy when types say what's
>> needed and what isn't.  uint8_t says too much.  uint_least8_t is better
>> because it says exactly what's needed and what isn't.  The suggestion
>> had nothing to do with portability.
>
> Surely uint_least8_t specifies even more?
>
> That's not a type I've come across anywhere else. And I'd be interested
> in which machine it would map to anything other than 'unsigned char' (as
> it does on x64.
>
> I can sort of see the use-case, but it sounds niche: you need a u8 type
> but don't want to commit to exactly u8 because on some unusual
> architecture you don't want it to jump through hoops to give you u8,
> when u16 would do just as well. But specifying u16 anyway would be
> wasteful everywhere else.
>
> And then there's uint_fast8_t; I can't even make a guess at that. All I
> knows is that the last thing I want to see in source code is
> uint_least8_t and uint_fast8_t (maybe 'const' too!) cluttering things up
> and obscuring the underlying code. uint8_t is bad enough.
>
> I want to see something like 'byte' or 'u8'. For the unusual situation
> above, deal with that in usercode via a special usertype.

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.

The "fast" types, on the other hand, can have real use in embedded
systems that span a range of target devices. Some 16-bit, 32-bit and
64-bit processors require extra masking or extending instructions when
dealing with 8-bit or 16-bit data (the original Alpha processor was
particularly bad). So local variables of a larger type are more
efficient. On the other hand, these will be much less efficient if the
code is then compiled for an 8-bit target. The main type of interest
here is "(u)int_fast8_t", since most uses of "int_fast16_t" can be
written as "int".

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.

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.