Converting unsigned long to string in C

[Antoninus Twink]

From the horse's mouth, folks.

Yes - shock horror, Richard isn't one of the C language fundamentalists
who believe that the ISO Standard was given to us on tablets of gold,
and shouldn't be interpreted in the light of *real world* experience.

 

[William Pursell]

...
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
I hate this "fad" of using "sizeof n". It reads horribly.

What ""fad""? sizeof and its usage has been part of C for a long time.

The fad that I have almost never seen it in production code because
.... it reads horribly. Simple. Practical reasons. The clique here use
it all the time because they are the clique.

It reads very well, actually, but if you insist on using parentheses
perhaps you would be okay with:
char s[(CHAR_BIT * (sizeof n) + 2) / 3 + 1];

 

[santosh]

Richard wrote:
Richard Heathfield <[email protected]> writes:

...
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];

I hate this "fad" of using "sizeof n". It reads horribly.

What ""fad""? sizeof and its usage has been part of C for a long
time.

The fad that I have almost never seen it in production code because
.... it reads horribly. Simple. Practical reasons. The clique here
use it all the time because they are the clique.

It reads very well, actually, but if you insist on using parentheses
perhaps you would be okay with:
char s[(CHAR_BIT * (sizeof n) + 2) / 3 + 1];

Don't you mean?

char s[(CHAR_BIT * sizeof(n) + 2) / 3 + 1];

 

[Richard Harter]

Indeed.

The simple fact is that sizeof *is* an operator, whether anyone likes
it or not. You (that's a generic "you") can use all the parentheses
you like in your own code, but if you can't cope with "sizeof x", then
you can't cope with valid C.

If K&R had chosen to use, say, "$" rather than "sizeof" as the symbol
for this operator, we wouldn't be having this discussion.

That's open to question. The problem is that sizeof is a hack;
it is not an operator in the same way that operators such as + et
al are operators. (The fact that the standard calls sizeof an
operator is beside the point - the issue is not what the thing is
called but rather its intrinsic propertires.)

In effect, ordinary C operators are functions in disguise, i.e.
functions with special syntax. Their arguments are the values of
expressions; they "return" values within the C type system. C
does not have type valued variables; nonetheless sizeof has a
type as an "argument", either explicitly as in sizeof(int) or
implicitly as in sizeof(x). The fact that in some instances the
parentheses are not needed and in others it is required is a
hack.

Since sizeof (or $ if you want to call it that) requires
parentheses in some circumstance IMHO it would have made more
sense to call it a function (in the C sense of functions of
course) rather than an operator and always require parentheses.

Be that as it may, always using parentheses seems to me to be the
better policy because it is simple and consistent.

(There are C coding styles that I dislike, but I can deal with them,
and even use them if necessary. I don't question the motivation or
integrity of those whose opinions differ from mine.)

--
Keith Thompson (The_Other_Keith) <[email protected]>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

 

[Serve Laurijssen]

So you dont think it reads horribly?

I have entered the 21st century and use syntax highlighting. You can
immediately spot the operator with or without parentheses. Things reading
horribly is only one's opinion

 

[Eric Sosman]

In effect, ordinary C operators are functions in disguise, i.e.
functions with special syntax. Their arguments are the values of
expressions; [...]

This is true only of a subset of C's operators.
Obvious exceptions are the -> and . operators, whose
right-hand operands are not values at all. Also, I
think you'll find it difficult to write functions that
are equivalent to ++ and -- (in either position), to =
and += and their brethren, to (short) and (unsigned char)
and such, to ?:, and to ().

 

[CBFalconer]

From the horse's mouth, folks.

Please don't feed the troll.

 

[Richard Tobin]

It would remove one of my objections, anyway.

Since sizeof (or $ if you want to call it that) requires
parentheses in some circumstance IMHO it would have made more
sense to call it a function (in the C sense of functions of
course) rather than an operator and always require parentheses.

A way to make the current situation seem slightly more consistent in
the grammar would be to add a production:

type-expression:
( type-name )

and change some other productions:

cast-expression:
unary-expression
type-expression cast-expression

unary-expression
[...]
sizeof unary-expression
sizeof type-expression

and in C99:

postfix-expression:
[...]
type-expression { initializer-list }
type-expression { initializer-list , }

Whenever type names are used in expressions they are parenthesized,
but that's not apparent without looking closely at the grammar.

Of course, all this would be simpler if keywords were in a different
font from identifiers, as in Algol 68.

-- Richard

 

[CBFalconer]

Richard Tobin said:

...except for:

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

In general, those require #include <iso646.h> and are all #defines.

 

[J. J. Farrell]

...
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
I hate this "fad" of using "sizeof n". It reads horribly.

What ""fad""? sizeof and its usage has been part of C for a long time.

The fad that I have almost never seen it in production code because
.... it reads horribly. Simple. Practical reasons. The clique here use
it all the time because they are the clique.

What on earth are you on about? What "reads horribly" about it? What
"practical reasons"? I can only assume you haven't seen much production
code.

 

[J. J. Farrell]

Richard wrote:
...
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
I hate this "fad" of using "sizeof n". It reads horribly.
What ""fad""? sizeof and its usage has been part of C for a long
time.
The fad that I have almost never seen it in production code because
.... it reads horribly. Simple. Practical reasons. The clique here
use it all the time because they are the clique.

It reads very well, actually, but if you insist on using parentheses
perhaps you would be okay with:
char s[(CHAR_BIT * (sizeof n) + 2) / 3 + 1];

Don't you mean?

char s[(CHAR_BIT * sizeof(n) + 2) / 3 + 1];

Can't see why he would - that makes even less sense. At least William
Pursell's parenthesis helps readers who aren't confident of operator
precedence; yours does nothing except obfuscate things a little.

 

[John Bode]

Richard wrote:
...
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
I hate this "fad" of using "sizeof n". It reads horribly.
What ""fad""? sizeof and its usage has been part of C for a long time.

The fad that I have almost never seen it in production code because
.... it reads horribly. Simple. Practical reasons. The clique here use
it all the time because they are the clique.

What on earth are you on about? What "reads horribly" about it? What
"practical reasons"? I can only assume you haven't seen much production
code.

Richard thinks code written in a straightfoward, non-IOCCC style
"reads horribly." And I have a feeling I know what his vision of
"production code" is; I've seen it at past jobs, and it isn't pretty.
It works, it's fast, just pray to God you never have to maintain it.

 

[John Bode]

I have no objection to operators that are words, but C doesn't have
any apart from sizeof. That makes it look out of place and
distracting in an expression. In a language where such things
were common, it wouldn't.

It is of course just a matter of taste.

-- Richard

Yeah, sizeof is an odd duck, but C is a menagerie of odd ducks, so
it's never really bothered me.

 

[Micah Cowan]

It would remove one of my objections, anyway.

Of course, the standards committee would've felt compelled to introduce
another trigraph for it. Perhaps ??S ?

Or I suppose they could solve the ISO-646 problem by making ¤ an
alternative spelling for the same operator.

(Hi y'all)

 

[Richard Bos]

Of course, the standards committee would've felt compelled to introduce
another trigraph for it. Perhaps ??S ?

None of the other trigraphs have letters in them. Perhaps ??% ?

Or I suppose they could solve the ISO-646 problem by making ¤ an
alternative spelling for the same operator.

I don't think that's in EBCDIC... it's certainly not in ASCII, and it's
even missing from some ASCII-based charsets (e.g., ISO-8859-15 and -16).
So you'd dissolve a bit more than just ISO-646.

(Hi y'all)

Hey, look who's back! Where've you been?

Richard

 

[Richard Bos]

Strictly speaking, 10/10 == 11/11.

Maybe Mr. Heathfield plays guitar for Spinal Tap?

Richard

 

[Richard Bos]

Richard thinks code written in a straightfoward, non-IOCCC style
"reads horribly." And I have a feeling I know what his vision of
"production code" is; I've seen it at past jobs, and it isn't pretty.
It works, it's fast, just pray to God you never have to maintain it.

IME, that kind of code usually _was_ fast, back when the hand-
optimisations in it still made sense. In the mean time, computers have
moved on, and the "clever" code has been overtaken by clear, simply
written, 99%-ISO C code.

Richard

 

[Richard Heathfield]

Micah Cowan said:

(Hi y'all)

wb Micah - pull up a troll and make yourself comfortable. There's plenty of
C in the fridge - help yourself.

Now then, what's all this I hear about trigraphs? We've only just recovered
from the /last/ discussion thereof...

 

[Richard Heathfield]

Richard Bos said:

Maybe Mr. Heathfield plays guitar for Spinal Tap?

Film at el... er, ten.

 

[William Pursell]

Richard wrote:
...
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
I hate this "fad" of using "sizeof n". It reads horribly.
What ""fad""? sizeof and its usage has been part of C for a long
time.
The fad that I have almost never seen it in production code because
.... it reads horribly. Simple. Practical reasons. The clique here
use it all the time because they are the clique.

It reads very well, actually, but if you insist on using parentheses
perhaps you would be okay with:
char s[(CHAR_BIT * (sizeof n) + 2) / 3 + 1];

Don't you mean?

char s[(CHAR_BIT * sizeof(n) + 2) / 3 + 1];

No. Richard is arguing that that syntax is more readable,
while others (myself included) don't like it because it
makes sizeof look like a function. At least once in the
past, I can recall worrying about the runtime cost
of computing sizeof, so I can readily attest to how
easy it is to make that mistake. I believe that
(sizeof n) is an acceptable compromise, although
I find the version with no superfluous parentheses
to be the most readable.