Question

[Max]

Can I ask C questions here?

 

[Richard Tobin]

Can I ask C questions here?

I don't know. Why not give it a try and see if you're up to it?

-- Richard

 

[vippstar]

Can I ask C questions here?

I'm not sure anymore, you haven't done a good start. Your first
question certainly was not about C.

 

[user923005]

I'm not sure anymore, you haven't done a good start. Your first
question certainly was not about C.

However, topicality is always topical.

 

[Harald van Dijk]

However, topicality is always topical.

Regardless of whether topicality is topical on this newsgroup, there are
places where it is not, so no, topicality is not always topical. As for
this newsgroup, in my opinion, it should never be considered topical, only
tolerated when there is not a more appropriate place for discussion, and
while I'm aware I'm in the minority on this, I don't remember seeing any
reasons for treating it as topical, even unconvincing ones, other than
tradition.

That said, vippstar's response is perfectly correct. Given that Max has
asked a question which was not about C, he has not yet demonstrated he is
able to ask C questions here. We have yet to find out.

 

[Antoninus Twink]

Can I ask C questions here?

You can try. However, you should be aware that many people will refuse
to answer your C questions if they pertain to any use of C in the real
world, and will instead be caustic and rude to you. However, some people
will try to answer your questions.

 

[Max]

I don't know. Why not give it a try and see if you're up to it?

If I compile this function

unsigned short div(unsigned short a, unsigned short b)
{
return a / b;
}

with warnings turned on, I am informed that

Warning test.c: 3 Assignment of int to unsigned short. Possible loss of precision
Warning test.c: 4 Assignment of int to unsigned short. Possible loss of precision
Warning test.c: 4 Assignment of int to unsigned short. Possible loss of precision

(line 3 is the line with the return statement, line 4
is the line with the closing brace)

(1) What does that mean, specifically, what is precision
in this context?

(2) How do I get rid of them? I tried all sorts of casts,
unsuccessfully. In a program with lots of such functions,
real problems can easily get lost, but I don't want to
disable warnings.

 

[Walter Roberson]

You can try. However, you should be aware that many people will refuse
to answer your C questions if they pertain to any use of C in the real
world, and will instead be caustic and rude to you.

Not in my experience. The trouble comes when people start trying to
talk about things that are *not* about the C language, but instead
just happen to be accessed through a C program.

 

[Default User]

Regardless of whether topicality is topical on this newsgroup, there
are places where it is not, so no, topicality is not always topical.

That's wrong. Topicality is topical in all newsgroups. It has to be. If
you couldn't discuss what was and was not topical, how would anyone
know?




Brian

 

[Antoninus Twink]

Not in my experience. The trouble comes when people start trying to
talk about things that are *not* about the C language, but instead
just happen to be accessed through a C program.

Personally I try to answer questions when I can on "C and related
subjects broadly interpreted", i.e. Standard C, POSIX/Windows APIs, C++,
threads, assembly, hardware, etc. If people aren't interested, they
could just kill the thread. But no, they always have to go on and on
about their narrow view of topicality - trotting it out a dozen times a
day doesn't seem to weary them.

 

[Antoninus Twink]

That's wrong. Topicality is topical in all newsgroups. It has to be. If
you couldn't discuss what was and was not topical, how would anyone
know?

Read the charter? Use their common sense? Apply their own judgment?
Ignore the delirious rantings of topicality obsessives?

 

[Walter Roberson]

If I compile this function

unsigned short div(unsigned short a, unsigned short b)
{
return a / b;
}

with warnings turned on, I am informed that

Warning test.c: 3 Assignment of int to unsigned short. Possible loss of precision
Warning test.c: 4 Assignment of int to unsigned short. Possible loss of precision
Warning test.c: 4 Assignment of int to unsigned short. Possible loss of precision

(line 3 is the line with the return statement, line 4
is the line with the closing brace)

(1) What does that mean, specifically, what is precision
in this context?

When you do calculations upon char or short values, they are
automatically converted into int values for the duration of the
calculation, with the calculation being done in int. The result of
the expression, when used in a return statement, will be converted to
the type of the return value "as if by assignment". Thus, your code
body is equivilent to {footnote 1}

return (unsigned short)((int)a / (int)b)

The compiler is noticing that you have an int expression
(that is, the result of the division) and that it has to be converted
to an short for function value return purposes, and is warning you
that an unsigned short cannot (usually) hold the range of values
that an int can, and hence that there could be a problem with the
conversion of the expression to unsigned short. Of course, we know
that the result of a division by an integer is always smaller than
the original numerator (unless the divisor is 0, in which case you
have a problem anyhow), so we as humans know that the potential for
bad results is not actually there in this case, but your compiler
isn't quite smart enough to tell that. If you were to change the /
operator to * or + or - then you *could* get a result that was too
large to represent as an unsigned short, leading to problems.


/* footnote 1: the rules about what type -exactly- the value will be
converted into, take a few sentances to express. On -most- systems,
the result is that signed and unsigned short would both be
converted into signed int, but on some systems (particularily DSPs)
the result of the rules is that signed and unsigned short would
both be converted into unsigned int. On those systems, your code body
would instead be equivilent to

return (unsigned short)((unsigned int)a / (unsigned int)b)

*/

(2) How do I get rid of them? I tried all sorts of casts,
unsuccessfully. In a program with lots of such functions,
real problems can easily get lost, but I don't want to
disable warnings.

return (unsigned short)(a/b)

should probably get rid of the warning; if not, then

return (unsigned short)((unsigned int)a / (unsigned int)b)

probably would. But compilers are allowed to produce any warning
messages they want as long as they compile code that does not violate
any language constraints, so there is no guarantee that you will be
able to silence the warning.

 

[Ben Bacarisse]

If I compile this function

unsigned short div(unsigned short a, unsigned short b)
{
return a / b;
}

with warnings turned on, I am informed that

Warning test.c: 3 Assignment of int to unsigned short. Possible loss of precision
Warning test.c: 4 Assignment of int to unsigned short. Possible loss of precision
Warning test.c: 4 Assignment of int to unsigned short. Possible loss of precision

(line 3 is the line with the return statement, line 4
is the line with the closing brace)

(1) What does that mean, specifically, what is precision
in this context?

On many systems (yours included) int can represent all the values of
unsigned short and more. This has two consequences:

(a) before the arithmetic happens the values of a and b are converted
to int;

(b) when the int result is returned, some bits might be lost in the
conversion to unsigned short. This might be a real worry if you
were multiplying, for example. It matters less with a divide.

The message is little confusing because it talks about assignment, but
parameter passing and value returning are treated much like assignment
in C so the compiler is probably borrowing a message from another
context. In this context precision refers to the number of
representable values -- wider types, in general, have greater
precision.

(2) How do I get rid of them? I tried all sorts of casts,
unsuccessfully. In a program with lots of such functions,
real problems can easily get lost, but I don't want to
disable warnings.

What compiler is it? You may has to ask in a specific group. The
message does not correspond to any that come from ne of the compiler I
have access to, so I can't help there. With the Intel compiler,
writing

return (unsigned short)(a / b);

gets rid of a similar message.

 

[Harald van Dijk]

That's wrong. Topicality is topical in all newsgroups. It has to be. If
you couldn't discuss what was and was not topical, how would anyone
know?

I hadn't read the claim as applying only to newsgroups because there was
nothing suggesting so. You would know by asking in a place dedicated to
such questions or by asking people in private (via e-mail or otherwise).
Both methods are common enough on forums and mailing lists, and there is
no technical reason why it would not also be possible at least on the
moderated newsgroups.

For newsgroups such as this one, since no meta.comp.lang.c exists, you
would be able to ask here even if it's off-topic. It would be tolerated
because there's no better place to ask. I made sure to mention this in my
message. Please re-read it.

 

[user923005]

Regardless of whether topicality is topical on this newsgroup, there are
places where it is not, so no, topicality is not always topical. As for
this newsgroup, in my opinion, it should never be considered topical, only
tolerated when there is not a more appropriate place for discussion, and
while I'm aware I'm in the minority on this, I don't remember seeing any
reasons for treating it as topical, even unconvincing ones, other than
tradition.

That said, vippstar's response is perfectly correct. Given that Max has
asked a question which was not about C, he has not yet demonstrated he is
able to ask C questions here. We have yet to find out.

You are wrong. As a long standing USENET tradition, discussion of
what is topical is *always* topical.

 

[Falcon Kirtaran]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

However, topicality is always topical.

That only really holds true in American-style high school debate, in my
experience.

- --
- --Falcon Darkstar Kirtaran
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJIUIPwAAoJEKmxP9YxEE4rlzcP/iu9zBIj4GhUMXVsFukbiK8G
nZHUV+lL/qMcuttxdKwbHBxNkWdDCd2/hztkJjCmHnJvtXmkxgl7ILKLOjcdI34q
aup2tS+SRAmZllcyI+kFd6xjZG0Y5hzmdjCFomKzdfi35YkU9d4s+aYNivWi8qyN
4tovaB1bgE99e8oVuj1hANGOIivrFnfqIIJ3wsSMoabKZmOdFGDJsgmWMLEnhnj+
cFL/BqPcwXSblyfW5XksLzx6/5RJG8LFKoagA1YYfKX2XYslSZ47Sf8OK9IAkD0b
UzgBmfY6FFnF+FoGA9SlcDUOdVlu0Geju5PhgTbLPD9zo9FUnF9K3nRSi3ECTpxQ
VTA4TcZ/q0gVEZkIjzLtdjcJ2bVVKDGTwoMFDfRNdpHsgMJXxTDPuq1NbUzkf4P+
/rEGv7paqQ7GJQqsQPCUa7aH1/5pXgQ8SV+x6HOyyNwNrKRIb+imkdc/Zl6XQU4q
ecrfq5yyLKFP6zu6S3WjK4iJjOoB74WXF7RCOSu/m1sWZ6aZnuEcEnA9w35LL/25
tJ9E+tR1Q/kAdIhVh7L6xWNPJykzE6mkBbXZepjGplBc2B42Ug4H2XjfHTbnFOyA
CZXOTC5T3BJcCEcQ2rhTMm4MOH7dp8vKphazXK0xAtDhghBpJiu7uSr+c5U21ckq
Wy357VxCzwiJEQjeNMXC
=PEsB
-----END PGP SIGNATURE-----

 

[Falcon Kirtaran]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You are wrong. As a long standing USENET tradition, discussion of
what is topical is *always* topical.

Is this a standard usenet tradition?

- From your headers:

"Content-Type: text/plain; charset=EUC-KR"

- --
- --Falcon Darkstar Kirtaran
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJIUISBAAoJEKmxP9YxEE4rEJ4P/2L28pF3cDbKQiZXWye4eP+u
vQAxNicPrf/YhItPEkvGAx6ogSilwuab99I+WRjtsHGOO1vp+AzUUW8D3ecACkVk
hKh+uw78iFS0U6QrhTjII5AvoPqkXIILhv9Qkc/EOWRq+uH6l+RSpYBzCLrO5OAJ
YqwgS2BEXL7M/xwPC7RyWsJ5IW1tLiJT0dTsd5TqX2uLLkVPymUeAwdArsuZcmeJ
TdQMsdynOnunOonqK0vsm4W+AyRHLHK4IJkTISOSXD6oASMu2tHHrxvZEy7K0745
AK8KFPlJlYpXX83t8Puscla4d1ajGpN6kfMP9rMQZi6C2Eoi60yUfNPandgs9ToS
5hRHgBlqLT63IJ/OyOAO5z78vJk7IALHqyV9kU/VW4dnluzjntneGAeLwXjCfwH2
yR/fTW8dSxriBMRaw+n10Lj/yuKcoYgOqxsBx2SyJ7EvHFBtynn2lNvqYPyxWxbZ
E840Dd8OnunYlrHuYya+F9wMM4YRmVMn5GTW0Rb4+//c9lAD0J7mCEjv7ihkWOnz
74X+Qd7mfbjHfPfHsGaD3eWQkkMIQxDYBCCzkhq/Y9noXEGF6NftkaZMW7dLrceX
PEeLptZRBQj51oKppQyyhRBFUbJB/ybuREfQUSmfipRfHIda7g0QtJS3qaFzJJN6
uXj90BTnBXZMeUXWW56d
=k5vB
-----END PGP SIGNATURE-----

 

[Falcon Kirtaran]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Max should also be aware that Twink is a known troll, and should
always be completely ignored. PLONKing is even better.

<menacingly gets out a can of gas and some sundry incendiary goods>

Burn the trolls! Burn! Burn!

- --
- --Falcon Darkstar Kirtaran
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJIUIUQAAoJEKmxP9YxEE4rvzMP/3AYA0YwxguJeRgMqeneWNyZ
o5VGkGsACBgJ833zwPasWkbgV9H3spI6TlKL92MRZVgaxRgV2IXWwWyfd1aGxtFW
btKH+T9SJ8f8qcGLqPiTOJm5Qpm9zvFlntbx6b0i1VhODSKNbEirJR1mHOSBh9JE
hBSO6s4+I+F7BKHfMHwZbRzkUd4vh2+rlYpZ4/OfUSVqA+u9O2mF/gE+3LxHtYLf
t3ySWa25r9+TtUkFaYTULXS5l/lbbeE1dpJztb/YrUmI705dahzN1WxQ+Qm0hfE5
dUkot2afo2cmzfVQz8DM/OuLTS7fqRj4/LL6NV41um+cvbcnnLpDYfR27UJKSpVc
HqDV/DRW+IySh8Io/18SZLcqFi7tpKATNl9g2AWb9lh4wYB7s+EFFFfMfYuUnqrr
K4HtB1DvC6A5LXtNilOelvFDjrvBX3gjLeoTFdymgCVFuIfzW9FFMNqtrW25khNX
lZs/1ec0Szd9he+v5wZK/9bY/OGfKdjD1kjD1mzWTBIwe5E2tyHAWv1UFWjZ7iwN
82plhEkmoL/zwY0E6uOGLEnj8BikJjGnSBU/4IhmJ7/RASBGqKDTXKCGNNnM/zYJ
Yb1jtk4CyuxdieZlaQMKUuASwFjr7W6HtcsUFkNPyieE283qnYkHGF4NtZl1U9pl
Y13E146MRINilJuqcIrz
=G8UW
-----END PGP SIGNATURE-----

 

[Harald van Dijk]

You are wrong.

Whether topicality is topical is a question of fact. If I say topicality
is off-topic here, you can say I'm wrong. Whether topicality should be
topical is opinion.

As a long standing USENET tradition, discussion of what
is topical is *always* topical.

Yes, it's tradition, but do you also have any reason why topicality
_should_ be considered topical?

 

[Richard Bos]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


That only really holds true in American-style high school debate, in my
experience.

- --
- --Falcon Darkstar Kirtaran
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJIUIPwAAoJEKmxP9YxEE4rlzcP/iu9zBIj4GhUMXVsFukbiK8G
nZHUV+lL/qMcuttxdKwbHBxNkWdDCd2/hztkJjCmHnJvtXmkxgl7ILKLOjcdI34q
aup2tS+SRAmZllcyI+kFd6xjZG0Y5hzmdjCFomKzdfi35YkU9d4s+aYNivWi8qyN
4tovaB1bgE99e8oVuj1hANGOIivrFnfqIIJ3wsSMoabKZmOdFGDJsgmWMLEnhnj+
cFL/BqPcwXSblyfW5XksLzx6/5RJG8LFKoagA1YYfKX2XYslSZ47Sf8OK9IAkD0b
UzgBmfY6FFnF+FoGA9SlcDUOdVlu0Geju5PhgTbLPD9zo9FUnF9K3nRSi3ECTpxQ
VTA4TcZ/q0gVEZkIjzLtdjcJ2bVVKDGTwoMFDfRNdpHsgMJXxTDPuq1NbUzkf4P+
/rEGv7paqQ7GJQqsQPCUa7aH1/5pXgQ8SV+x6HOyyNwNrKRIb+imkdc/Zl6XQU4q
ecrfq5yyLKFP6zu6S3WjK4iJjOoB74WXF7RCOSu/m1sWZ6aZnuEcEnA9w35LL/25
tJ9E+tR1Q/kAdIhVh7L6xWNPJykzE6mkBbXZepjGplBc2B42Ug4H2XjfHTbnFOyA
CZXOTC5T3BJcCEcQ2rhTMm4MOH7dp8vKphazXK0xAtDhghBpJiu7uSr+c5U21ckq
Wy357VxCzwiJEQjeNMXC
=PEsB
-----END PGP SIGNATURE-----

Given the above massive load of useless random number crap, your
experience on Usenet can't come to much. Keep that shit in e-mail.

Richard