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

[Ben Bacarisse]

bm********@gmail.com writes:

Could any one tell me how to convert a unsigned long value into string
(char *) ?

You want to look at snprintf with a format of "%lu". If you are not
lucky enough to have snprintf use sprintf with a large enough buffer.

--
Ben.

[santosh]

bm********@gmail.com wrote:

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

sprintf and snprintf will do what you want.

<OT>

You probably want to use string streams in C++, rather than a primitive
like _ultoa.

</OT>

[Richard Heathfield]

bm********@gmail.com said:

Hi,
Could any one tell me how to convert a unsigned long value into string
(char *) ?

A char * isn't a string. It's just a way of pointing to one.

In C++ there is a function _ultoa so wanted a similar one in C .

C++ has no such function. It is almost certainly an extension provided by
your implementation.

First, make sure you have enough storage for the string representation of
the unsigned long value. In general, if there are CHAR_BIT bits in a byte
and sizeof(unsigned long) bytes in an unsigned long, then the largest
value that can be stored in an unsigned long will have a decimal
representation no longer than (CHAR_BIT * sizeof(unsigned long) + 2) / 3,
and you'll need a byte for the null terminating character, so we have:

#include <limits.h>
#include <stdio.h>

int main(void)
{
unsigned long n = 12345; /* whatever */
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
sprintf(s, "%lu", n);
printf("The string value is [%s]\n", s);
return 0;
}

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

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

bm********@gmail.com said:

>Hi,
Could any one tell me how to convert a unsigned long value into string
(char *) ?

A char * isn't a string. It's just a way of pointing to one.

>In C++ there is a function _ultoa so wanted a similar one in C .

C++ has no such function. It is almost certainly an extension provided by
your implementation.

First, make sure you have enough storage for the string representation of
the unsigned long value. In general, if there are CHAR_BIT bits in a byte
and sizeof(unsigned long) bytes in an unsigned long, then the largest
value that can be stored in an unsigned long will have a decimal
representation no longer than (CHAR_BIT * sizeof(unsigned long) + 2) / 3,
and you'll need a byte for the null terminating character, so we have:

#include <limits.h>
#include <stdio.h>

int main(void)
{
unsigned long n = 12345; /* whatever */
char s[(CHAR_BIT * sizeof n + 2) / 3 + 1];
sprintf(s, "%lu", n);
printf("The string value is [%s]\n", s);
return 0;
}

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

[Serve Laurijssen]

"Richard Heathfield" <rj*@see.sig.invalidschreef in bericht
news:9Z******************************@bt.com...

bm********@gmail.com said:
First, make sure you have enough storage for the string representation of
the unsigned long value. In general, if there are CHAR_BIT bits in a byte
and sizeof(unsigned long) bytes in an unsigned long, then the largest
value that can be stored in an unsigned long will have a decimal
representation no longer than (CHAR_BIT * sizeof(unsigned long) + 2) / 3,
and you'll need a byte for the null terminating character, so we have:

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

I would do two things different. First its not immediately obvious where the
buffer size calculation comes from so I'd put that in a macro.
Second, if n becomes signed in the future you need one more space if n
becomes negative. The code gets a little easier to maintain then

[Richard Tobin]

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

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

I agree. Since all other operators in C are symbols rather than
words, and function names are words rather than symbols, it's more
natural to treat sizeof as if it were a function.

And of course the operator-like form doesn't work for type names,
so it's more consistent to avoid it.

-- Richard

--
:wq

[Martin Ambuhl]

bm********@gmail.com wrote:

Hi,
Could any one tell me how to convert a unsigned long value into string
(char *) ?

sprintf and snprintf do that job quite nicely.

In C++ there is a function _ultoa so wanted a similar one in C .

You have been misled. There is no C++ function named _ultoa. Your
implementation may provide a non-standard, non-portable function with
that name, and if it does so for C++, it may do so for C. There are,
with less than a handful of exceptions, no standard functions in C or
C++ with names beginning with an underscore. If you see such an
identifier, be alert to the possibility that you are looking at a
completely non-standard, non-portable identifier, and even the next
edition of your implementation might not support it

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

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

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

I agree. Since all other operators in C are symbols rather than
words, and function names are words rather than symbols, it's more
natural to treat sizeof as if it were a function.

And of course the operator-like form doesn't work for type names,
so it's more consistent to avoid it.

I disagree. Since sizeof really is an operator, it makse sense to
treat it as one. Making it look like a function call is misleading.

Do you use extra parentheses on return statements?

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

[Richard Tobin]

In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:

>I agree. Since all other operators in C are symbols rather than
words, and function names are words rather than symbols, it's more
natural to treat sizeof as if it were a function.

And of course the operator-like form doesn't work for type names,
so it's more consistent to avoid it.

>I disagree. Since sizeof really is an operator,

What exactly do you mean by this? In what sense is it "really an
operator"? It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.

>Making it look like a function call is misleading.

Making it look like an operator is "misleading" too; if it was an
operator you ought to be able to write "sizeof int". But anyway, what
do you mean, misleading? Who could it mislead?

>Do you use extra parentheses on return statements?

"return" is a statement; it can't be used in an expression. There
isn't anything for it to be consistent with, and there aren't two
different syntaxes depending on its operand.

-- Richard

--
:wq

[Eric Sosman]

Richard Tobin wrote:

In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:
[...]

>I disagree. Since sizeof really is an operator,

What exactly do you mean by this? In what sense is it "really an
operator"? It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.

The sense in which it "really is an operator" is the
sense in which the Standard uses the term "operator." For
example,

6.5.3.4 The sizeof operator
Constraints
1) The sizeof operator shall not be applied to [...]
Semantics
2) The sizeof operator yields the size [...]

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

[J. J. Farrell]

Richard wrote:

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

...

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

[J. J. Farrell]

Richard Tobin wrote:

In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:

>>I agree. Since all other operators in C are symbols rather than
words, and function names are words rather than symbols, it's more
natural to treat sizeof as if it were a function.

And of course the operator-like form doesn't work for type names,
so it's more consistent to avoid it.

>I disagree. Since sizeof really is an operator,

What exactly do you mean by this? In what sense is it "really an
operator"?

Presumably in the sense that it is an operator.

It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.

It's an operator, just like any other operator except for an extension
which allows it to operate on parenthesized type names.

... if it was an
operator you ought to be able to write "sizeof int".

Why? To be consistent with 'a *= int' and '47 + int'? As far as I
recall, sizeof is the only operator which can operate on type names.
There's a rule that type names have to be in parenthesis when being
operated on. I expect that if any other operator gets added which can
operate on type names, the same rule will apply.

...

[Richard Tobin]

In article <oJ******************************@comcast.com>,
Eric Sosman <es*****@ieee-dot-org.invalidwrote:

>>I disagree. Since sizeof really is an operator,

>What exactly do you mean by this? In what sense is it "really an
operator"? It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.

The sense in which it "really is an operator" is the
sense in which the Standard uses the term "operator."

Which is not relevant to whether it's more or less confusing to write
it without parentheses.

-- Richard
--
:wq

[Mark McIntyre]

Richard Tobin wrote:

In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:

>>I agree. Since all other operators in C are symbols rather than
words, and function names are words rather than symbols, it's more
natural to treat sizeof as if it were a function.

And of course the operator-like form doesn't work for type names,
so it's more consistent to avoid it.

>I disagree. Since sizeof really is an operator,

What exactly do you mean by this? In what sense is it "really an
operator"?

In the sense that it actually is an operator, as defined by the standard

[Mark McIntyre]

Richard Tobin wrote:

In article <oJ******************************@comcast.com>,
Eric Sosman <es*****@ieee-dot-org.invalidwrote:

>>>I disagree. Since sizeof really is an operator,

>>What exactly do you mean by this? In what sense is it "really an
operator"? It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.

> The sense in which it "really is an operator" is the
sense in which the Standard uses the term "operator."

Which is not relevant to whether it's more or less confusing to write
it without parentheses.

So what?
Your question above was "in what sense is it really an operator?". The
answer is that it is defined as such.
--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[pete]

Richard Heathfield wrote:

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

Where are you getting "+ 2" from?

--
pete

[Ben Bacarisse]

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

Richard Heathfield wrote:

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

--
Ben.

[Eric Sosman]

pete wrote:

Richard Heathfield wrote:

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

Where are you getting "+ 2" from?

3 - 1

;-)

Familiar trick: To divide integers M / N and get the
ceiling ("round up") instead of floor ("truncate"), divide
(M + N - 1) / N instead. Work it out for yourself; choose
a value like N==3 and go through the possibilities.

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

[Richard Heathfield]

Serve Laurijssen said:

>
"Richard Heathfield" <rj*@see.sig.invalidschreef in bericht
news:9Z******************************@bt.com...

<snip>

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

I would do two things different. First its not immediately obvious where
the buffer size calculation comes from so I'd put that in a macro.
Second, if n becomes signed in the future you need one more space if n
becomes negative. The code gets a little easier to maintain then

The second point is trivially true (but it's still a point worth making).
The first point is more a matter of opinion but, as a matter of fact, I
agree with you.

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

In article <tu****************@en-nntp-02.am2.easynews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>>>>I disagree. Since sizeof really is an operator,

>>>What exactly do you mean by this? In what sense is it "really an
operator"? It's a unique thing, with its own special syntax.
It doesn't work like either an operator or a function.

>> The sense in which it "really is an operator" is the
sense in which the Standard uses the term "operator."

>Which is not relevant to whether it's more or less confusing to write
it without parentheses.

>So what?
Your question above was "in what sense is it really an operator?". The
answer is that it is defined as such.

Look up "context" in a dictionary.

-- Richard
--
:wq

[Richard Tobin]

In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:

>Note that some languages have a number of operators that use keywords
(For example, Ada has "and", "or", "xor", "not", "mod", "rem", "abs",
"not", even though the fundamental arithmetic operators use the usual
symbols "+", "-", "/", "*".)

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

[Richard Heathfield]

Richard Tobin said:

In article <87************@kvetch.smov.org>,
Keith Thompson <ks***@mib.orgwrote:

>>Note that some languages have a number of operators that use keywords
(For example, Ada has "and", "or", "xor", "not", "mod", "rem", "abs",
"not", even though the fundamental arithmetic operators use the usual
symbols "+", "-", "/", "*".)

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

....except for:

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

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

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.

-- Richard
--
:wq

[Richard Heathfield]

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

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

[Mark McIntyre]

Richard Tobin wrote:

In article <tu****************@en-nntp-02.am2.easynews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

(RT wrote)

>>Which is not relevant to whether it's more or less confusing to write
it without parentheses.

>Your question above was "in what sense is it really an operator?". The
answer is that it is defined as such.

Look up "context" in a dictionary.

Look up "irrelevant". Its an operator in any context. If you don't like
that, raise a DR. If you meant to ask a different question, then say so.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Richard]

"J. J. Farrell" <jj*@bcs.org.ukwrites:

Richard wrote:

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

...

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

[Richard]

Mark McIntyre <ma**********@spamcop.netwrites:

Richard Tobin wrote:

>In article <tu****************@en-nntp-02.am2.easynews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

(RT wrote)

>>>Which is not relevant to whether it's more or less confusing to write
it without parentheses.

>>Your question above was "in what sense is it really an
operator?". The answer is that it is defined as such.

Look up "context" in a dictionary.

Look up "irrelevant". Its an operator in any context. If you don't
like that, raise a DR. If you meant to ask a different question, then
say so.

So you dont think it reads horribly?

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

x = x + sizeof y + 3;

reads like crap in the context of the C programming language.

Operator? Get out of it.

sizeof(y) is obvious to anyone. The above is horrendous. And I dont
believe anyone that says its "as obvious" in the context of other C
code.

[Eric Sosman]

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.

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

[Jean-Marc Bourguet]

Richard <de***@gmail.comwrites:

Operator? Get out of it.

I can write

x = sizeof (ptr+1)->field;

which is valid, but would be meaningless if sizeof was a function returning
an int.

I can't write

x = (sizeof)(ptr);

which would be valid if sizeof was a function.

Luckily, I don't think there is a case where interpreting sizeof as a
function lead to a valid but different parse as using its true definition
excepted variations on the obfuscated contest candidate:

x = sizeof(i)[ptr];
You may want to force additional parenthesis in your coding standard if you
find them more readable. I've no strong opinion about them. But don't let
your cosmetic preference (as cosmetic as prefering the absence of them)
induce you into error, sizeof is not a function and doesn't behave like
one.

A+

--
Jean-Marc

[Keith Thompson]

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.

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

[Richard Heathfield]

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

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

[Keith Thompson]

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

(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) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

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

On Mon, 25 Feb 2008 10:36:16 +0000, Richard Heathfield wrote:

Richard Tobin said:

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

...except for:

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

They're operators in C++. They're macros in C.

[santosh]

Harald van D?k wrote:

On Mon, 25 Feb 2008 10:36:16 +0000, Richard Heathfield wrote:

>Richard Tobin said:

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

...except for:

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

They're operators in C++. They're macros in C.

Any reason to make them macros instead of keywords, as in C++?

[Richard Heathfield]

santosh said:

Harald van D?k wrote:

<snip>

>They're operators in C++. They're macros in C.

Any reason to make them macros instead of keywords, as in C++?

By making them macros, the Standard attempts to avoid breaking existing
code. After all, these names are in C90 user namespace! So the Standard
stops you from getting access to these operators unless you specifically
request it by #including iso646.h - or at least, that seems to me to be
the most likely rationale.

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

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

On Tue, 26 Feb 2008 00:26:45 +0530, santosh wrote:

Harald van D?k wrote:

>On Mon, 25 Feb 2008 10:36:16 +0000, Richard Heathfield wrote:

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

...except for:

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

They're operators in C++. They're macros in C.

Any reason to make them macros instead of keywords, as in C++?

To minimise the modifications required for compilers, I believe. It's only
recently that C++ compilers handle the alternate spellings of the
operators correctly (including such things as the required diagnostic for
the syntax error in #ifdef and), when all that complexity is really not
necessary. For correct programs, the only effective difference between a
macro "and" and an operator "and" is how they are stringised, and this
will affect very few programs.

[santosh]

Harald van D?k wrote:

On Tue, 26 Feb 2008 00:26:45 +0530, santosh wrote:

>Harald van D?k wrote:

>>On Mon, 25 Feb 2008 10:36:16 +0000, Richard Heathfield wrote:
Richard Tobin said:
I have no objection to operators that are words, but C doesn't
have any apart from sizeof.

...except for:

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

They're operators in C++. They're macros in C.

Any reason to make them macros instead of keywords, as in C++?

To minimise the modifications required for compilers, I believe. It's
only recently that C++ compilers handle the alternate spellings of the
operators correctly (including such things as the required diagnostic
for the syntax error in #ifdef and), when all that complexity is
really not necessary. For correct programs, the only effective
difference between a macro "and" and an operator "and" is how they are
stringised, and this will affect very few programs.

Thanks to both Richard and Harald.

[Antoninus Twink]

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

[Antoninus Twink]

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.

[William Pursell]

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

[santosh]

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

[Serve Laurijssen]

"Richard" <de***@gmail.comschreef in bericht
news:fp**********@registered.motzarella.org...

Mark McIntyre <ma**********@spamcop.netwrites:

>Richard Tobin wrote:

>>In article <tu****************@en-nntp-02.am2.easynews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

(RT wrote)

>>>>Which is not relevant to whether it's more or less confusing to write
it without parentheses.

Your question above was "in what sense is it really an
operator?". The answer is that it is defined as such.

Look up "context" in a dictionary.

Look up "irrelevant". Its an operator in any context. If you don't
like that, raise a DR. If you meant to ask a different question, then
say so.

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]

Richard Harter wrote:

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

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

[J. J. Farrell]

santosh wrote:

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

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]

On Feb 25, 4:29 am, [e-mail] (Richard Tobin) wrote:

In article <[e-mail]>,
Keith Thompson <[e-mail]:

Note that some languages have a number of operators that use keywords
(For example, Ada has "and", "or", "xor", "not", "mod", "rem", "abs",
"not", even though the fundamental arithmetic operators use the usual
symbols "+", "-", "/", "*".)

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

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

[CBFalconer]

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.

Please don't feed the troll.

--
[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 Heathfield wrote:

Richard Tobin said:

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

>>Note that some languages have a number of operators that use
keywords (For example, Ada has "and", "or", "xor", "not", "mod",
"rem", "abs", "not", even though the fundamental arithmetic
operators use the usual symbols "+", "-", "/", "*".)

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

...except for:

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

In general, those require #include <iso646.hand are all #defines.

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

[Micah Cowan]

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.

(Hi y'all)

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

[Richard Bos]

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

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