Converting unsigned long to string in C

[Richard Heathfield]

Serve Laurijssen said:

"Richard Heathfield" <[email protected]> schreef in bericht

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

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

[/QUOTE]

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

 

[Richard Tobin]

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

 

[Richard Heathfield]

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

 

[Richard Tobin]

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

[/QUOTE]

...except for:

* and
[...]

10/10 for pedantry.

-- Richard

 

[Richard Heathfield]

Richard Tobin said:

...except for:

* and
[...]

10/10 for pedantry.[/QUOTE]

Strictly speaking, it should be 11/11.

 

[Mark McIntyre]

(RT wrote)


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.

 

[Richard]

...

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]

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]

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.

 

[Jean-Marc Bourguet]

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+

 

[Keith Thompson]

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.

 

[Keith Thompson]

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

 

[Richard Heathfield]

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

 

[Harald van Dijk]

Richard Tobin said:

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

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

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

 

[Harald van Dijk]

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.

 

[Richard Heathfield]

santosh said:

Harald van D?k wrote:


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.

 

[santosh]

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]

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