Converting unsigned long to string in C

[Ben Pfaff]

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.

Or they could have added another alternative spelling to
iso646.h, say like this:
#define sizeof $
<g,d&r>

 

[Micah Cowan]

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

Yeah, but S looks more like $ than % does.

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.

Yeah; but those all have the $, don't they? I mentioned ¤ only because
in ISO-646 character sets, 0x24 can either represent $ or it can
represent ¤. AFAIK, there aren't any serious encodings (for instance,
ones that use both upper- and lower-case letters) that lack both. And it
seemed like ISO-646 was getting special treatment anyway.

Sorry, I'm afraid I became something of a character-set geek in my
absence. Got into ISO-646 by way of my interest in ISO-2022 character
set-switching sequences (which nobody actually _uses_, AFAICT, apart
from limited use for Asian encodings such as ISO-2022-JP).

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

Um... desperately trying to avoid newsgroups on which I was spending too
much time that was supposed to be going into work? We'll see if I can
participate a bit more moderately this time around.

Someone's been pestering me (gently) to get back on, too (ht Bill Ahern
).

 

[Micah Cowan]

Or they could have added another alternative spelling to
iso646.h, say like this:
#define sizeof $
<g,d&r>

<

u

 

[santosh]

"J. J. Farrell" <[email protected]> writes:

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];

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.

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.

Stylistically, I prefer the sizeof N form. Of course for types one has
to use sizeof(T), but I don't like (sizeof N) or, even worse,
(sizeof(T)).

 

[Richard]

From the horse's mouth, folks.

So you're willing to forego common sense and use an aesthetically
horrible syntax because it's an "operator"? I have NEVER known an
industry C programmer use that horrible style. Really.

The fact is that you DO have a choice on how to use sizeof. One IS
confusing (by majority concensus) and the other reads a lot
better. Which to use? Hmmm .....

or do you honestly maintain that

x = x + sizeof y + 3;

is as clear cut as

x= x+sizeof(y)+3;

Do you really think that?

Sometimes you guys try to be that little too clever.

 

[Richard]

Indeed.

The simple fact is that sizeof *is* an operator, whether anyone likes
it or not.

You seem purposely to miss the point. I dont care if it IS an
operator. It is much neater and easier to read in its "function mode".

 

[Richard]

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.

Thank you. I am astonished at the clique's inability to open their
eyes. That idiot CBFalconer I expected it from as he appears to revel in
being a pompous pseudo intellectual with zero practical experience in
the real world and an inability to work in any team environment , but
would have expected better from Eric.

 

[santosh]

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

Aesthetically horrible to whom?

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

That doesn't mean much.

The fact is that you DO have a choice on how to use sizeof. One IS
confusing (by majority concensus)

What majority concensus? Have you done a study?

and the other reads a lot
better. Which to use? Hmmm .....

sizeof(T) reads no better than sizeof T.

or do you honestly maintain that

x = x + sizeof y + 3;

is as clear cut as

x= x+sizeof(y)+3;

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.

Do you really think that?

Sometimes you guys try to be that little too clever.

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.

 

[Richard]

Keith Thompson said:

Richard Tobin said:
I have no objection to operators that are words, but C doesn't have
any apart from sizeof.

...except for:

* and
[...]

10/10 for pedantry.

Strictly speaking, it should be 11/11.

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

It depends on what you mean by it. In context, 10/10 suggests "10 out of
10", rather as if it were the score on a test, i.e. in the spirit of "10
questions right out of 10 questions asked", rather than "10 divided by
10". Now, "10 right out of 10 asked" is /not/ the same as "11 right out of
11 asked" (the latter being the more difficult achievement), so 10/10
isn't necessarily == 11/11.

(Of course, in a C context they do evaluate to the same result, but we all
knew that we all knew that already, right?)

Another insightful discussion, getting right to the heart of a juicy C
problem...

Please! You're getting off Mr Heathfield's chosen topic.

 

[Richard]

Aesthetically horrible to whom?

To pretty much anyone I have ever worked with. You find it "easy to
read"? use some common sense before replying and compare the examples. A
bit like bracketing : one can be clever and know all the rules or one
can be safe and keep it clean.

That doesn't mean much.

Yes it does. In the real world. in real coding standards.

What majority concensus? Have you done a study?

Yes. 15 years of industry C programming.

sizeof(T) reads no better than sizeof T.

Yes it does. To me and nearly everyone I have worked with in years of
programming.

Do you say

x = strlen l;

? No. Oh of course, because strlen is a function and sizeof is an
"operator". It's messy.

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.

garbage. you're plying the company tune here.

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.

Well not, because onyl the clique are being clever about it. I dont need
them supporting me - I have my own experiences.

If you argue that example 1 above is clearer than 2 then god help
you. It is totally "out of style" with the rest of C code IMO.

 

[santosh]

To pretty much anyone I have ever worked with. You find it "easy to
read"?

I didn't say it's easy to read. I said that neither is better or worse
than the other. They are just two different forms, like say:

unsigned long n;
long unsigned m;

It's not even comparable, IMO, to:

*(p + i);

and

p

in which the first form *was* found unreadable enough to warrant the
second one. Just like:

p->m

instead of

(*p).m

Yes it does. To me and nearly everyone I have worked with in years of
programming.

Do you say

x = strlen l;

? No. Oh of course, because strlen is a function and sizeof is an
"operator". It's messy.

By that token many things about C are "messy". It's a language to get
the job done, not to win some contest of beauty or elegance.

garbage. you're plying the company tune here.

Nope. It's you who is plying the "contrarian" tune here. As I said, the
first example is more readable mainly because of the lack of whitespace
in the second one, rather than the rather trivial difference in sizeof.

If you argue that example 1 above is clearer than 2 then god help
you. It is totally "out of style" with the rest of C code IMO.

You mean the rest of C code that *you* have worked with?

 

[Richard Tobin]

It's not even comparable, IMO, to:

*(p + i);

and

p

in which the first form *was* found unreadable enough to warrant the
second one.

Brackets of one kind or another were used for array indexing long before
C-style pointer arithmetic. p is not "warranted" becase *(p + i) is
hard to read; it's the original form and the equivalence is just C's
clever way of unifying pointers and arrays.

-- Richard

 

[Eric Sosman]

Brackets of one kind or another were used for array indexing long before
C-style pointer arithmetic. p is not "warranted" becase *(p + i) is
hard to read; it's the original form and the equivalence is just C's
clever way of unifying pointers and arrays.

The readability improvement of brackets becomes even
more striking with multi-dimension arrays:

*(*(*(array+i)+j)+k) = 42;
vs.
array[j][k] = 42;

 

[Default User]

Richard wrote:

Nope. It's you who is plying the "contrarian" tune here.

That's correct. He's a troll, and best ignored. He'll continue with
"anti-clique" pronouncements and other inflammatory remarks as long as
you want to play.




Brian

 

[Keith Thompson]

You seem purposely to miss the point. I dont care if it IS an
operator. It is much neater and easier to read in its "function mode".

As I'm sure you've noticed, I rarely respond to you; I'll make an
exception for once. At least in this case you're talking about C
rather than (or in addition to) complaining about other posters.

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,
I prefer to treat it as one. *Because* it's not a function,
I prefer not to use a fake function-call-like syntax for it.
I could choose to uniformly apply the "sizeof" operator only to
parenthesized expressions (or, similarly, to use only parenthesized
expressions in return statements). I choose not to. Unlike you,
I do care about what's in the standard.

When I read and write C code, I tend to think of the underlying
concepts, as expressed in the language grammar and elsewhere, at
least as much as the superficial appearance. I prefer "int *ptr;"
to "int* ptr;" because the former reflects the language grammar and
semantics (*ptr is an int, rather than ptr is an int*). I don't
write "return(x);" because it's a return keyword followed by a
parenthesized expression, and the parentheses are unnecsssary.
I declare the second parameter to main as "char **argv" rather than
"char *argv[]" because the former expresses what it really is, a
pointer to pointer to char. I don't write "sizeof(n)" because it's
a sizeof keyword (operator) applied to a parenthesized expression;
the parentheses are unnecessary and provide no additional clarity
*for me*.

There's room for legitimate disagreement on all these stylistic
points, and I've never claimed otherwise. And I'm sure that a
strictly consistent application of the principle I've outlined
leads to some things that *I* would find ugly and unclear. I don't
claim to be 100% consistent (though I'd be interested in seeing
any examples; I might re-think a few things.)

Now if you prefer to write "sizeof(n)" because you happen to like it
better, that's fine with me; I have no trouble reading such code,
even if I wouldn't have written it that way myself. It doesn't
cause me to question your competence or honesty. If you want
to tell me that I should do the same, that's ok too; I'm free to
ignore your advice. If you tell me that I and everyone else who
feels as I do is being dishonest, that our reasonable coding style,
fully supported by the language standard, violates "common sense",
that it's nothing more than the "clique" being "clever", I find
that just a bit annoying.

Please note that most of what I've written here has been statements
about my own personal preferences, my own mental state. If you wish
to make a fool of yourself by disputing those statements, about which
you can have no knowledge other than what I've told you, feel free.

 

[Antoninus Twink]

That's correct. He's a troll, and best ignored. He'll continue with
"anti-clique" pronouncements and other inflammatory remarks as long as
you want to play.

*Yaaaaaawn*

Is that the whining sound of a broken record that I hear?

 

[Harald van Dijk]

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.

I think something's wrong with either your or my newsreader. € is part of
ISO-8859-15, but ¤ (which appeared correctly in Micah Cowan's message) is
not.

 

[Richard]

That's correct. He's a troll, and best ignored. He'll continue with
"anti-clique" pronouncements and other inflammatory remarks as long as
you want to play.




Brian

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

 

[Richard]

As I'm sure you've noticed, I rarely respond to you; I'll make an

I rarely post something you would be interested.

exception for once. At least in this case you're talking about C
rather than (or in addition to) complaining about other posters.

In addition to. This group is a mess IMO.

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.

I prefer to treat it as one. *Because* it's not a function,
I prefer not to use a fake function-call-like syntax for it.
I could choose to uniformly apply the "sizeof" operator only to
parenthesized expressions (or, similarly, to use only parenthesized
expressions in return statements). I choose not to. Unlike you,
I do care about what's in the standard.

I DO care about whats in the standard. But that doesn't mean I have to
palm off readability in order to prove my standard knowledge.

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.

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

 

[Michael Mair]

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

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 have NEVER known an
industry C programmer use that horrible style. Really.

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

The fact is that you DO have a choice on how to use sizeof. One IS
confusing (by majority concensus)

Please provide numbers and something backing them.

and the other reads a lot
better. Which to use? Hmmm .....

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

or do you honestly maintain that

x = x + sizeof y + 3;

is as clear cut as

x= x+sizeof(y)+3;

Do you really think that?

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

Sometimes you guys try to be that little too clever.

???


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.
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.
Note that part of our customers wishes that there are
parentheses around the returned expression in production code.

In my experience, more people are wrong on things like
(*p)[5]
vs.
*p[5]
or complex expressions involving << and >> operators.


Cheers
Michael