Converting unsigned long to string in C

[John Bode]

The fact that I think you're a vapid wannabe does not make me a
troll. All you do is post "OT" reprimands.

I'm *deadly* serious about this use of sizeof. I did not expect you to
have an opinion of your own. But someone will give you one soon enough I
suspect ...

In my 18 years of programming at 6 different companies, I've *never*
heard anyone rant about sizeof in this manner. Never. It simply
wasn't an issue for anyone that I've worked with. Hell, when I
figured out that sizeof could be called on objects as well as types, I
was *happy* about it, syntax be damned; no more having to worry about
synchronizing types between declarations and calls, a la

T *x;
...
x = malloc(ELEMENTS * sizeof *x);

I can change the type of x without breaking code, as opposed to if I
had used "sizeof(T)". Is it less than elegant? Sure, but what in C
*isn't* less than elegant?

The people I worked with tended to get more worked up about
requirements and schedules than language peculiarities. I did get one
career Ada programmer spinning when I explained that array indexing in
C is commutative. That's about it for language outrage, though.

Of course, YMMV.

 

[pete]

unsigned long n = 12345; /* whatever */
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];

Where are you getting "+ 2" from?

I image it is habit from the general case.

Here is low-down in case anyone is interested. It would be nice if
n_bits/3 were enough for the decimal representation of an unsigned
integer n_bits wide, but it is not. Interestingly is *is* enough for
C's unsigned long, since the longest integers for which this
expression fails to be large enough is 20 bits -- and C guarantees
more than 20 bits for unsigned long.

There are three bit sizes at which the more generous (n_bits + 1)/3 is
not enough: 1, 4, 7 and 10. The minimum range guaranteed for C's
unsigned int means that (CHAR_BIT * sizeof n + 1)/3 is enough for that
type, but not for unsigned char if CHAR_BIT is 10.

The upshot is that if the type not constrained, you need to add 2 and
divide by three and I imagine many people just remember this as rule
of thumb (I did until a few minutes ago!).

Obviously, add one for a sign bit and one for null as required.

Thank you.

I had considered

char itoa_buff[(value_bits) / 3 + 2];
char utoa_buff[(value_bits) / 3 + 1];

and found it to work for the smallest int:
(15 / 3 + 2) == 7 && sizeof "-32767" == 7
(16 / 3 + 1) == 6 && sizeof "65355" == 6

and also for a more common modern int:
(31 / 3 + 2) == 12 && sizeof "-2147483648" == 12
(32 / 3 + 1) == 11 && sizeof "4294967295" == 11

I then incorrectly assumed that it would work
for intermediate and larger bit numbers,
but now I can see that it doesn't work for 20 bit unsigned:
(20 / 3 + 1) == 7 && sizeof "1048575" == 8

 

[pete]

You seem purposely to miss the point.

You seem purposely to miss the point.

I dont care if it IS an operator.

That's the point.
Your opinions are annoying and nothing else.
That's the point.

 

[CBFalconer]

It would remove one of my objections, anyway.

And they would have been thoroughly criticized. '$' is not
available on many keyboards. Think UK, France, Germany, for
example. It is not a portable character.

 

[CBFalconer]

Richard wrote:
.... snip ...


On the contrary, the first statement is considerably better,
stylistically, than the second one. The lack of whitespace alone
impacts readability much more than the different forms of sizeof.


I'm not sure who is trying to be clever in this particular
situation. If we take this group as representative of the wider
C programming community (despite what the "contrarians" would
like us to believe), then your aversion to 'sizeof N' seems to
be confined to a very small minority. Thus far, no one here has
come out in support of your preference, as far as I can see.

I have no specific preference about sizeof, but use parens whenever
it appears to make the code clearer. However I DO have specific
preferences about blanks in statements, and those make the first
instance infinitely clearer to me. They also avoid silly mistakes.

 

[Old Wolf]

I agree. I don't know how anyone could mistake sizeof to be a function
after he has once learned that it is defined as a compile time
operator.

Except that it can be a runtime operator in C99..

BTW, trying to make sizeof look like a function only
shows that you don't understand how it works. Try
implementing a function that does the same thing as
sizeof..

 

[Richard Heathfield]

CBFalconer said:

And they would have been thoroughly criticized. '$' is not
available on many keyboards. Think UK, France, Germany, for
example. It is not a portable character.

$ is in the ASCII character set (code point 36) and the EBCDIC character
set (code point 91). It is present on French keyboards (between ^ and *),
Hungarian keyboards (sharing a key with e-acute), Polish keyboards
(sharing a key with that funny w-sounded L with the line through it) and
UK, German, Croatian, Slovak, Czech, Italian, Spanish, Latin American,
Portuguese, and Japanese keyboards (shift-4). It is rather more portable
than, say, the two square bracket characters [], which caused me one or
two (minor) portability problems when I was working on mainframes.

 

[Eric Sosman]

[...] *because* "sizeof" is an operator,

Exactly. But you do NOT have to think of it as one.

Right. And Carbon is a chemical element, but you do
NOT have to think of it as one. And 17 is a prime number,
but you do NOT have to think of it as one. And Richard
is a bleating troll, but you do NOT have to think of it
as one.

 

[Eric Sosman]

So you're willing to forego common sense and use an aesthetically
horrible syntax because it's an "operator"?

"Aesthetically horrible?" Good grief, we've got the
reincarnation of Oscar Wilde on our hands ...

> I have NEVER known an
> industry C programmer use that horrible style.

All I can conclude is that the sense would be
unchanged if the full stop came after the eighth word.

 

[Richard Tobin]

$ is in the ASCII character set (code point 36) and the EBCDIC character
set (code point 91). It is present on French keyboards (between ^ and *),
Hungarian keyboards (sharing a key with e-acute), Polish keyboards
(sharing a key with that funny w-sounded L with the line through it) and
UK, German, Croatian, Slovak, Czech, Italian, Spanish, Latin American,
Portuguese, and Japanese keyboards (shift-4). It is rather more portable
than, say, the two square bracket characters [], which caused me one or
two (minor) portability problems when I was working on mainframes.

The teletypes for the ICL mainframes I used in the 1970s didn't have a
$ key. They had a pound (sterling) key instead. This was of no
significance to the languages that used $ in their syntax (BASIC for
example) - they just used the pound symbol instead. On the other
hand, they didn't have lower case letters either.

But in any case, I was not advocating the use of $ as an operator in
C, just conceding that a symbol rather than a word would remove one of
my reasons for finding "sizeof x" unattractive. This subthread is
another example of CBFalconer's refusal to follow the thread of a
discussion but instead latch onto minor irrelevances and treat them as
if they were substantive refutations of the argument they were
peripheral to.

If the vertical bar symbol were not already used, I might suggest the
outfix operator |x|.

-- Richard

 

[Richard]

In my 18 years of programming at 6 different companies, I've *never*
heard anyone rant about sizeof in this manner.

It didnt start off as a "rant". I merely pointed out that its cleaner
one way than the other. The annoyance comes from the insistence of it
not being clearer to understand "because its really an operator". It is
ludicrous thinking.

 

[Richard]

Note that aesthetics usually depend on the one who is trying
to be aesthetically pleased.

Personally, I add unnecessary parentheses whenever the respective
coding guidelines demand them or whenever I suspect that the
maintenance programmers' eyes can grasp quicker what is going on
than if I do not set them.
In code I write for private use, this means that I am near the
minimum number of parentheses.

I always code for maintenance. And that means brackets.

You mean face to face, I guess. Via usenet, you know several if you
read comp.lang.c carefully.

Of course I mean face to face. On big projects with code rules and
guidelines for consistent look and feel to all code.

Please provide numbers and something backing them.

Everyone I have ever worked with pretty much other than those wanting to
be different for differences sake.

IMO, the problem is that we have one usage of sizeof that
necessitates parentheses and another that does not. Some people
seem to have problems with this "inconsistency".


Yes. If I needed to add parentheses to the former, I'd write
x = x + (sizeof y) + 3;



???


FWIW, at the moment, I am working in an environment where I
participated in writing the coding guidelines.
The reasoning behind many of the parenthesizing rules is that
not everyone knows the language sufficiently well to omit them
only when not needed.

Correct. However we do not need to code for complete nOObs either. But
bracketing keeps things straightforward for all - no thinking required.

For sizeof, we were essentially undecided but went indeed for
always parenthesizing the operand as half of the committee was
not aware that it was possible to omit them. For return, they
are not mandatory.

Fine.

But I still concur that

x=y+sizeof z + 3;

is confusing in the context of how most other C looks and this is much
clearer:

x=y+sizeof(z) + 3;

There is NO room for misunderstanding here and it just roles off the
eyes IMO.

 

[Richard]

You seem purposely to miss the point.


That's the point.
Your opinions are annoying and nothing else.
That's the point.

It takes a rare kind of fool to miss it twice. Well done.

 

[William Pursell]

Of course I mean face to face. On big projects with code rules and
guidelines for consistent look and feel to all code.

I think Richard is accurate about the percentage usage
of "sizeof x". Most programmers don't use it. Most
don't know it is valid syntax. Most production code
doesn't use it. Unfortunately it is also the case
that most programmers are ignorant and have no sense
of aesthetics. Richard obviously has a strong aesthetic
sense, which in this case is in disagreement with the
sensibility of many others in this thread. When I
first saw "sizeof x", I was annoyed that I hadn't seen
it long before, and thought it was amazing that I had
not. How did such an aesthetically appealing usage
avoid my eyes for so long? Because I was reading code
written by incompetent boobs with no aesthetic sense
who were probably following some absurd coding standard
written by persons who may or may not have
known that sizeof could be applied to an object and
mandated that it only be used in the form "sizeof(T)".
(Well, really, it's probably because I wasn't coding
very much at all, and what code I was reading was
obfuscated Perl, but that's a different story which
is clearly OT. Here on CLC, we must pretend that
C is the only language.)

In short, it is not because sizeof is an operator
that I use "sizeof x". It is because I find it
more aesthetically appealing. Richard's sense of
aesthetics is different.

 

[Keith Thompson]

[...]

I'm not missing your point; I'm simply disagreeing with you.

You find "sizeof n" ugly and difficult to read. That's fine;
I don't expect, or even particularly want, you to change your mind.

I find the "sizeof n" form cleaner and easier to read than the
"sizeof(n)" form. For me, *because* "sizeof" is an operator,

Exactly. But you do NOT have to think of it as one.

So what? I do think of "sizeof" as an operator. You're saying
there's something wrong with that. That's absurd.

[...]

I DO care about whats in the standard.

Glad to hear it. Note that that directly contradicts what you wrote
upthread.

But that doesn't mean I have to
palm off readability in order to prove my standard knowledge.

Nor do I. Readability is, almost by definition, in the eye of the
beholder.

I simply do not believe that in the context of other C code that this

x= y + sizeof z + a;

is easier to read than:

x= y + sizeof(z) + a;

for anyone.

And you maintain that belief in the fact of overwhelming evidence to
the contrary. I find them both about equally easy to read; the first
is perhaps slightly easier than the second, and I prefer it. You find
the form with the parentheses easier to read; that's fine. Your
denial that *I* find the form without parentheses easier to read is
stupid.

sizeof is a "special" thing IMO and therefore should the "like a
function" usage is much better so its not so special anymore.

Yes, sizeof is a "special" thing. I prefer not to hide that
specialness by pretending that it's a function.

I think I'll go back to ignoring you now, unless you somehow manage to
say something interesting.

 

[Richard Bos]

"Aesthetically horrible?" Good grief, we've got the
reincarnation of Oscar Wilde on our hands ...

Nah. When Oscar Wilde trolled ("All art is quite useless"), he was
entertaining.

Richard

 

[Ben Bacarisse]

I simply do not believe that in the context of other C code that this

x= y + sizeof z + a;

is easier to read than:

x= y + sizeof(z) + a;

for anyone.

I find it amazing that you can't believe this. I can see how you may
have moved in a programming circle where this looks odd and so, if you
ask, the people around you agree. But how can you make the leap to
not believing it of anyone? y + sizeof z + a has only one plausible
meaning in C and only one plausible meaning even if you don't know C.

To anyone exposed to languages with many word-like operators, or to
those where juxtaposition implies a tight binding, it will be
obvious. For it to have any meaning but the right one, the syntax
would have to be absurd.

 

[Bartc]

Richard Tobin said:


...except for:

* and
* and_eq
* bitand
* bitor
* compl
* not
* not_eq
* or
* or_eq
* xor
* xor_eq

I thought this was some sort of joke, but yes, these are actually in my C99
document as macros.

But, why? Every C programmer knows and loves && and friends, why did the
standard have a sudden urge to be sensible and turn C into something it
isn't?

And macros in lower-case too! (I suppose some attempt to avoid
user-namespace pollution.)

I think though eyebrows would be raised if anyone actually posted code with
these 'operators' in. Especially mixed with the originals.

But not sure about the _eq versions: 'and=', 'or=' and so on would have been
adequate.

Maybe the standard should have gone a bit further and defined lengthof() to
return the bound of an array. Using sizeof for this is rather clumsy.

I suppose my real quibble is the use of the macro system in C, which I'm
sure must have dogged its development; if anyone comes up with a real
enhancement, someone else is bound to come up with an ugly macro hack which
does 90% of it - badly.

And the macro system which I'm guessing was put there for the benefit and
edification of the users, instead has been used by the standard as a cheap
way of extending the language.

 

[santosh]

I simply do not believe that in the context of other C code that this

x= y + sizeof z + a;

is easier to read than:

x= y + sizeof(z) + a;

for anyone.

I find it amazing that you can't believe this. I can see how you may
have moved in a programming circle where this looks odd and so, if you
ask, the people around you agree. But how can you make the leap to
not believing it of anyone? [...]

Richard has unfortunately gradually developed a "Spinoza" like complex,
wherein he is compelled to suspect as posturing anything that a poster
whom he considers as a part of the hypothetical "clique" says.

<snip>

 

[santosh]

I thought this was some sort of joke, but yes, these are actually in
my C99 document as macros.

But, why? Every C programmer knows and loves && and friends, why did
the standard have a sudden urge to be sensible and turn C into
something it isn't?

I believe it was to alleviate problems for programmers working with
non-standard keyboards where some of these symbols were hard to
generate.

And macros in lower-case too! (I suppose some attempt to avoid
user-namespace pollution.)

I think though eyebrows would be raised if anyone actually posted code
with these 'operators' in. Especially mixed with the originals.

I have never yet seen such C code.

But not sure about the _eq versions: 'and=', 'or=' and so on would
have been adequate.

Maybe the standard should have gone a bit further and defined
lengthof() to return the bound of an array. Using sizeof for this is
rather clumsy.

Could have. But it's easy enough to compute with sizeof.

int arr[4];

size_t size_of_arr = sizeof arr / sizeof arr[0];

I suppose my real quibble is the use of the macro system in C, which
I'm sure must have dogged its development; if anyone comes up with a
real enhancement, someone else is bound to come up with an ugly macro
hack which does 90% of it - badly.

And the macro system which I'm guessing was put there for the benefit
and edification of the users, instead has been used by the standard as
a cheap way of extending the language.

Can you propose a better way?