Converting unsigned long to string in C

[bmshivaraj]

Hi,
Could any one tell me how to convert a unsigned long value into string
(char *) ?
In C++ there is a function _ultoa so wanted a similar one in C .
Regards,
Shivaraj

[Richard Bos]

Keith Thompson <ks***@mib.orgwrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

Richard Tobin said:

10/10 for pedantry.

Strictly speaking, it should be 11/11. :-)

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

Maybe Mr. Heathfield plays guitar for Spinal Tap?

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 <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Bos]

John Bode <jo*******@my-deja.comwrote:

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]

Richard Bos said:

Keith Thompson <ks***@mib.orgwrote:

>Richard Heathfield <rj*@see.sig.invalidwrites:

Richard Tobin said:
10/10 for pedantry.

Strictly speaking, it should be 11/11. :-)

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

Maybe Mr. Heathfield plays guitar for Spinal Tap?

Film at el... er, ten.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[William Pursell]

On Feb 25, 8:08 pm, santosh <[e-mail]:

William Pursell wrote:

On Feb 25, 4:30 pm, Richard <[e-mail]:

"J. J. Farrell" <[e-mail]:

Richard wrote:
Richard Heathfield <[e-mail]:

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

--
William Pursell

[Ben Pfaff]

Micah Cowan <mi***@cowan.namewrites:

Richard Tobin wrote:

>In article <47****************@news.sbtc.net>,
Richard Harter <cr*@tiac.netwrote:

>>On Mon, 25 Feb 2008 09:57:51 -0800, Keith Thompson
<ks***@mib.orgwrote:
If K&R had chosen to use, say, "$" rather than "sizeof" as the symbol
for this operator, we wouldn't be having this discussion.

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.

Or they could have added another alternative spelling to
iso646.h, say like this:
#define sizeof $
<g,d&r>
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Micah Cowan]

Richard Bos wrote:

Micah Cowan <mi***@cowan.namewrote:

>Richard Tobin wrote:

>>In article <47****************@news.sbtc.net>,
Richard Harter <cr*@tiac.netwrote:

On Mon, 25 Feb 2008 09:57:51 -0800, Keith Thompson
<ks***@mib.orgwrote:
If K&R had chosen to use, say, "$" rather than "sizeof" as the symbol
for this operator, we wouldn't be having this discussion.
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 ? :)

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

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

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

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

>(Hi y'all)

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 J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

[Micah Cowan]

Ben Pfaff wrote:

Micah Cowan <mi***@cowan.namewrites:

>Richard Tobin wrote:

>>In article <47****************@news.sbtc.net>,
Richard Harter <cr*@tiac.netwrote:

On Mon, 25 Feb 2008 09:57:51 -0800, Keith Thompson
<ks***@mib.orgwrote:
If K&R had chosen to use, say, "$" rather than "sizeof" as the symbol
for this operator, we wouldn't be having this discussion.
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.

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

<

u

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

[santosh]

William Pursell wrote:

On Feb 25, 8:08 pm, santosh <[e-mail]:

>William Pursell wrote:

On Feb 25, 4:30 pm, Richard <[e-mail]:
"J. J. Farrell" <[e-mail]:

Richard wrote:
Richard Heathfield <[e-mail]:

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

Eric Sosman <Er*********@sun.comwrites:

Richard wrote:

>>
it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard

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]

Keith Thompson <ks***@mib.orgwrites:

Eric Sosman <Er*********@sun.comwrites:

>Richard wrote:

>>it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard

From the horse's mouth, folks.

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]

Antoninus Twink <no****@nospam.invalidwrites:

On 25 Feb 2008 at 17:12, Eric Sosman wrote:

>Richard wrote:

>>>
it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard

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.

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]

Richard wrote:

Eric Sosman <Er*********@sun.comwrites:

>Richard wrote:

>>>
it makes no sense to me whatsoever and I dont give a monkeys uncle
about whats in the standard

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

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]

Antoninus Twink <no****@nospam.invalidwrites:

On 25 Feb 2008 at 18:01, Richard Heathfield wrote:

>Keith Thompson said:

>>Richard Heathfield <rj*@see.sig.invalidwrites:
Richard Tobin said:
In article <xc******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>>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]

santosh <sa*********@gmail.comwrites:

Richard wrote:

>Eric Sosman <Er*********@sun.comwrites:

>>Richard wrote:

it makes no sense to me whatsoever and I dont give a monkeys uncle
about whats in the standard

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

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.

>

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

That doesn't mean much.

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

>

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

Yes. 15 years of industry C programming.

>

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

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.

>

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

garbage. you're plying the company tune here.

>

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

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]

Richard wrote:

santosh <sa*********@gmail.comwrites:

>Richard wrote:

>>Eric Sosman <Er*********@sun.comwrites:

Richard wrote:
>
it makes no sense to me whatsoever and I dont give a monkeys uncle
about whats in the standard

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

Aesthetically horrible to whom?

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[i]

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

p->m

instead of

(*p).m

<snip>

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

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.

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

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.

<snip>

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]

In article <fq**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:

>It's not even comparable, IMO, to:

*(p + i);

and

p[i]

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[i] 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
--
:wq

[Eric Sosman]

Richard Tobin wrote:

>
Brackets of one kind or another were used for array indexing long before
C-style pointer arithmetic. p[i] 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[i][j][k] = 42;

--
Er*********@sun.com

[Default User]

santosh wrote:

Richard wrote:

garbage. you're plying the company tune here.

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]

Richard <de***@gmail.comwrites:

Keith Thompson <ks***@mib.orgwrites:

>Eric Sosman <Er*********@sun.comwrites:

>>Richard wrote:
it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard

From the horse's mouth, folks.

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

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.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Antoninus Twink]

On 26 Feb 2008 at 17:08, Default User wrote:

santosh wrote:

>Richard wrote:

garbage. you're plying the company tune here.

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.

*Yaaaaaawn*

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

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Tue, 26 Feb 2008 07:14:57 +0000, Richard Bos wrote:

Micah Cowan <mi***@cowan.namewrote:

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

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]

"Default User" <de***********@yahoo.comwrites:

santosh wrote:

>Richard wrote:

garbage. you're plying the company tune here.

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

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

[Michael Mair]

Richard wrote:

Eric Sosman <Er*********@sun.comwrites:

>>Richard wrote:

<Context: sizeof (NotAType) vs sizeof NotAType>

>>>it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard

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

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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[John Bode]

On Feb 26, 1:26 pm, Richard <[e-mail]:

"Default User" <[e-mail]:

santosh wrote:

Richard wrote:

garbage. you're plying the company tune here.

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

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]

Richard wrote:

>
Keith Thompson <ks***@mib.orgwrites:

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

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.

--
pete

[Old Wolf]

On Feb 27, 12:54 am, santosh <[e-mail]:

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

[CBFalconer]

santosh wrote:

>
Richard wrote:

.... snip ...

>

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

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Richard Tobin wrote:

Richard Harter <cr*@tiac.netwrote:

>Keith Thompson <ks***@mib.orgwrote:

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

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

CBFalconer said:

Richard Tobin wrote:

>Richard Harter <cr*@tiac.netwrote:

>>Keith Thompson <ks***@mib.orgwrote:

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

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.

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Eric Sosman]

Richard wrote:

Keith Thompson <ks***@mib.orgwrites:

>>
[...] *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
es*****@ieee-dot-org.invalid

[Eric Sosman]

Richard wrote:

Eric Sosman <Er*********@sun.comwrites:

>Richard wrote:

>>it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard

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

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

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Richard Tobin]

In article <1v******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>$ 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
--
:wq

[Richard]

John Bode <jo*******@my-deja.comwrites:

On Feb 26, 1:26 pm, Richard <[e-mail]:

>"Default User" <[e-mail]:

santosh wrote:

>Richard wrote:

garbage. you're plying the company tune here.

>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

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.

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]

Michael Mair <Mi**********@invalid.invalidwrites:

Richard wrote:

>Eric Sosman <Er*********@sun.comwrites:

>>>Richard wrote:

<Context: sizeof (NotAType) vs sizeof NotAType>

>>>>it makes no sense to me whatsoever and I dont give a monkeys uncle about
whats in the standard

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

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.

>

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

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

>

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

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

>

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

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]

pete <pf*****@mindspring.comwrites:

Richard wrote:

>>
Keith Thompson <ks***@mib.orgwrites:

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

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.

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

[Richard Bos]

Eric Sosman <es*****@ieee-dot-org.invalidwrote:

Richard wrote:

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

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

Richard

[Ben Bacarisse]

Richard <de***@gmail.comwrites:

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.

--
Ben.

[santosh]

Ben Bacarisse wrote:

Richard <de***@gmail.comwrites:

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

[Richard]

Ben Bacarisse <be********@bsb.me.ukwrites:

Richard <de***@gmail.comwrites:

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

For starters theres the

"is it sizeof(x)+y" or "sizeof(x+y)" double take. For seconds, well, I
give up.

I do not believe you don't get my point here. sizeof is a one off in C as
far as I can see. And you reckoning this "one off" is easy and as clear as
"sizeof(y)"?

I cant see it myself.

My experience is that almost nowhere other than here have I seen "sizeof
x + y" used in preference to "sizeof(x)+y";

[Richard]

santosh <sa*********@gmail.comwrites:

Ben Bacarisse wrote:

>Richard <de***@gmail.comwrites:

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

No he hasn't. He knows that the clique are very proud of their ability
to use standards C and the ability to use something as fundamentally
"silly" as this alternative syntax is, frankly, rather amusing. I would
hazard a guess that his alternative usage is in less than 1% of code
worldwide. Only in CLC is it "equally as clear".

[Ben Bacarisse]

Richard <de***@gmail.comwrites:

Ben Bacarisse <be********@bsb.me.ukwrites:

>Richard <de***@gmail.comwrites:

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

<snip>

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

For starters theres the

"is it sizeof(x)+y" or "sizeof(x+y)" double take. For seconds, well, I
give up.

To *you*? Don't you see. I've spent so many years using languages
that have word-like unary "operators" there is no double take. They
all bind very tightly. The first was SASL in 1978. It looks entirely
normal to me. Please try to accept that. I don't want to persuade
you to do anything you don't like, but I can't see how you can access
my internal parser.

I do not believe you don't get my point here.

I get it. My problem is that you don't believe me.

sizeof is a one off in C as
far as I can see. And you reckoning this "one off" is easy and as clear as
"sizeof(y)"?

Yes, it is a one-off, but only in C. It one of the parts of C that
looks quite natural -- to me. If C insisted on 'sizeof(expression)',
I'd go with that but it would strike me as odd that this built-in
operator required function syntax. The 'sizeof(type-name)' I can
accept since it is, in effect:

sizeof <applied to(some cast)

The brackets are there because of the ambiguous syntax of type names,
not because of a function-like call.

My experience is that almost nowhere other than here have I seen "sizeof
x + y" used in preference to "sizeof(x)+y";

I don't have much code here to scan, but my Linux kernel source has
more than 1200 instances of this form of sizeof. Much less than the
other form, but my point in not about the frequency of use, but about
your insistence than anyone who thinks differently about is being silly
(that is from another post in this thread).

--
Ben.

[Doug Miller]

In article <fq**********@registered.motzarella.org>, Richard <de***@gmail.comwrote:

>For starters theres the

"is it sizeof(x)+y" or "sizeof(x+y)" double take.

Don't be ridiculous; the meaning is just as obvious as in
x = y * a + b;

Or do you look at that statement and have trouble deciphering whether the
right side means ((y * a) + b) or (y * (a + b)) ?

[Richard Tobin]

In article <fq**********@registered.motzarella.org>,
Richard <de***@gmail.comwrote:

>I would
hazard a guess that his alternative usage is in less than 1% of code
worldwide. Only in CLC is it "equally as clear".

Not as little as that, but the Google n-gram corpus shows that
2,703,650 of 2,871,816 occurrences of sizeof are followed by an open
parenthesis. Of course we don't know how many of them are followed
by types.

-- Richard
--
:wq

[Micah Cowan]

Richard Tobin wrote:

In article <fq**********@registered.motzarella.org>,
Richard <de***@gmail.comwrote:

>I would
hazard a guess that his alternative usage is in less than 1% of code
worldwide. Only in CLC is it "equally as clear".

Not as little as that, but the Google n-gram corpus shows that
2,703,650 of 2,871,816 occurrences of sizeof are followed by an open
parenthesis. Of course we don't know how many of them are followed
by types.

It'd be interesting, for comparison, to determine how many occurrences
of malloc() do not get their values checked.

Of course, either way, ad populum is a ridiculous form of argument to
make regarding personal aesthetics. But then, so is more-or-less any
form of argument.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Richard Tobin wrote:

>>Richard Harter <cr*@tiac.netwrote:
Keith Thompson <ks***@mib.orgwrote:

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

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.

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

I believe you. However, I can definitely remember seeing a
definition where that character was called 'local currency symbol',
or similar. Maybe that preceded general tightening of the ASCII
spec. And you can't deny that many keyboards are missing it.
Especially typewriters (remember them?).

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Eric Sosman wrote:

Richard wrote:

>Keith Thompson <ks***@mib.orgwrites:

>>>
[...] *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.

Unfortunately it periodically nymshifts (without reforming) and
temporarily escapes the PLONK mechanism.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

Keith Thompson <ks***@mib.orgwrites:
[...]

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

Just for the record, this was not a serious suggestion. (It probably
would have caused problems on VMS, for one thing.)

On general, though, either having *all* operators represented by
puncutation symbols, or having several operators represented by
keywords, would avoid a lot of confusion. Having just one exceptional
operator represented by a keyword can, as we've seen, be problematic
for some. I have no problem with it myself, but I can understand that
others do.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Michael Mair]

Richard wrote:
<snip>

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.

This may be the heart of the problem.
When other people say "It is as easy / easier to read for me", you
just insist that they are wrong or lying.

If we had
x = y + * z + a;
and
x = y + *(z) + a;
I'd probably go for the former (but prefer
x = y + *z + a;
due to my internal parser) and would add parentheses (if pressed)
around the unary operator and its operand,
x = y + (*z) + a;
Just the same holds _in_ _my_ _case_ for sizeof.

This is just a matter of being used to it -- I basically learned
of "sizeof z" quite some time before I ever had the need to use
sizeof (T).

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

"It is like neither"?
I have no preference either way but I am not sure whether having
a function-like compile-time (or C99: mostly ha^H compile-time)
operator really is better than an operator working on expressions
and "casts".
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Richard Harter]

On Wed, 27 Feb 2008 15:25:06 GMT, sp******@milmac.com (Doug
Miller) wrote:

>In article <fq**********@registered.motzarella.org>, Richard <de***@gmail.comwrote:

>>For starters theres the

"is it sizeof(x)+y" or "sizeof(x+y)" double take.

Don't be ridiculous; the meaning is just as obvious as in
x = y * a + b;

Or do you look at that statement and have trouble deciphering whether the
right side means ((y * a) + b) or (y * (a + b)) ?

I dunno, I would expect that for most people it is not "just as
obvious". That * binds more closely than + is customary usage in
basic algebra. C (and most other computer languages) uses the
same precedence rules as ordinary usage. "sizeof" is an operator
peculiar to C; its precedence is necessarily idiosyncratic.

Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.