Converting unsigned long to string in C

[Default User]

I don't see him as a troll like Twink and McCormack; he strikes me as
someone who could contribute meaningfully to the group if he just got
over himself.

That's irrelevant. In fact, what he does is post messages designed to
cause trouble. He's a troll, pure and simple.





Brian

 

[Richard Harter]

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

You're right about it only being true of a subset - that's why I
used the word "ordinary". Still, your point is well taken; C
does have operators that don't take values. The term "operator"
is a bit misleading. This is not to say that it doesn't have a
well defined meaning in the C standard; merely that the usage in
the C standard is idiosyncratic. If we use function in the
broader context of computer science and mathematics rather than
the specific meaning of a C source function I would classify

-> and . as term formation symbols,
casts as ordinary functions, and
=, +=, etc as ordinary functions.

Assignment forms can be treated as functions with a caveat, the
issue being the C sequence point business. Pre and post
decrement and increment operators go even further into that murky
territory.




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

 

[CBFalconer]

.... snip ...


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

I simply use "y + sizeof x" to avoid reading problems. Similarly I
use "N * sizeof *p".

 

[Doug Miller]

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.

I disagree with respect to the degree of "obviousness" -- even if sizeof and +
were at the *same* level of precedence, left-to-right evaluation would still
guarantee that "sizeof x + y" would mean "(sizeof x) + y". It takes (IMHO) a
deliberately obtuse interpretation to suppose that it could mean "sizeof (x +
y)" instead.

 

[Jean-Marc Bourguet]

Would you like to see

printf "hello%s" "world";

or something equally as contrived for example?

I suggest that your learn about some other programming languages. For
example Haskell or one of the ML familly.

Yours,

 

[Jean-Marc Bourguet]

I disagree with respect to the degree of "obviousness" -- even if sizeof and +
were at the *same* level of precedence, left-to-right evaluation would still
guarantee that "sizeof x + y" would mean "(sizeof x) + y". It takes (IMHO) a
deliberately obtuse interpretation to suppose that it could mean "sizeof (x +
y)" instead.

If the grammar was changed in the obvious way so that sizeof x + y meant
sizeof(x+y), sizeof(x) + y would also be interpreted as sizeof((x)+y). BTW
sizeof(x)->field currently mean sizeof((x)->field).

Yours,

 

[Kenny McCormack]

...
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 - face it. For the in-crowd, using parens with sizeof is like
mixing primaries during daylight hours. Not done.

(We'll see if anyone catches the reference. Free peppermint candy to
anyone who does)

 

[David Thompson]

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

Where that () is funccall not grouping. Plus && || .

You're right about it only being true of a subset - that's why I
used the word "ordinary". Still, your point is well taken; C

I usually use 'computational' for this distinction.

does have operators that don't take values. The term "operator"
is a bit misleading. This is not to say that it doesn't have a
well defined meaning in the C standard; merely that the usage in
the C standard is idiosyncratic. If we use function in the
broader context of computer science and mathematics rather than
the specific meaning of a C source function I would classify

-> and . as term formation symbols,

See below.

casts as ordinary functions, and

You can treat a particular cast as a monadic value->value function,
but then you have an unboundedly extensible set of operators. To treat
cast syntax as a single operator you need a typevalued operand.

=, +=, etc as ordinary functions.

Assignment forms can be treated as functions with a caveat, the

As math function only if you include lvalues in values, which
'ordinary'<G> math i.e. arithmetic doesn't*; and as C function only if
you convert to pointers (or use C++ references). C's rough peers
(Fortran, PL/I, COBOL) do not allow assignment as a subexpression, and
F90 allows assignment to be overloaded for a userdefined (struct-like)
type as a (nonvalued and visibly nonpure) SUBROUTINE, not a valued
FUNCTION. (* Math in its full glory can manipulate almost anything the
mind can conceive, but with terminology far more bizarre and confusing
than the C standard. For example, part of modern computer cryptography
uses 'elliptic curves' which are neither elliptic nor curves.)

Those peers treat function call (where available), field selection,
and subscripting as (forms of) primaries rather than (sub)expressions
using an operator. PL/I has sort of the opposite problem: it used
named syntax for some things that 'ought' to be operators, partly
because of the 48-char BCDIC/card charset it had to support. For
example ABS(-3) is a 'built-in function' and so is SUBSTR(str,1,2)
_when used in an rvalue context_ but when the latter is used in an
lvalue context it is a 'pseudovariable'.

issue being the C sequence point business. Pre and post
decrement and increment operators go even further into that murky
territory.

AFAICS inc/dec don't cause any 'further' problem than += et al,
they're just (much) more frequent in common/idiomatic C.

- formerly david.thompson1 || achar(64) || worldnet.att.net