Question

[Max]

Can I ask C questions here?

[Richard Tobin]

Re: Question

In article <1292858.4WXqv0 htDk@aioe.org>, Max <invalid@invali d.invalidwrote:

>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



--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

[vippstar@gmail.com]

Re: Question

On Jun 12, 12:09 am, Max <inva...@invali d.invalidwrote:

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]

Re: Question

On Jun 11, 2:24 pm, vipps...@gmail. com wrote:

On Jun 12, 12:09 am, Max <inva...@invali d.invalidwrote: 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.

However, topicality is always topical.

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: Question

On Wed, 11 Jun 2008 14:42:00 -0700, user923005 wrote:

On Jun 11, 2:24 pm, vipps...@gmail. com wrote:

>On Jun 12, 12:09 am, Max <inva...@invali d.invalidwrote: >

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

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

[Malcolm McLean]

Re: Question


"Max" <invalid@invali d.invalidwrote in message news:

Can I ask C questions here?
>

I don't know whether you can or not, but you certainly may.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[Antoninus Twink]

Re: Question

On 11 Jun 2008 at 21:09, Max wrote:

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]

Re: Question

On 11 Jun 2008 21:23:46 GMT, richard@cogsci. ed.ac.uk (Richard Tobin) wrote:

>In article <1292858.4WXqv0 htDk@aioe.org>, Max <invalid@invali d.invalidwrote:
>

>>Can I ask C questions here?

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

Re: Question

In article <slrng50l9t.1b3 .nospam@nospam. invalid>,
Antoninus Twink <nospam@nospam. invalidwrote:

>On 11 Jun 2008 at 21:09, Max wrote:

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

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.
--
"Any sufficiently advanced bug is indistinguishab le from a feature."
-- Rich Kulawiec

[Default User]

Re: Question

Harald van Dijk wrote:

On Wed, 11 Jun 2008 14:42:00 -0700, user923005 wrote:

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.

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]

Re: Question

On 11 Jun 2008 at 23:12, Walter Roberson wrote:

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]

Re: Question

On 11 Jun 2008 at 23:16, Default User wrote:

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]

Re: Question

In article <15567233.JZ0Gp xGI0j@aioe.org> ,
Max <invalid@invali d.invalidwrote:

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

--
"Beauty, like all other qualities presented to human experience,
is relative; and the definition of it becomes unmeaning and
useless in proportion to its abstractness." -- Walter Pater

[Ben Bacarisse]

Re: Question

Max <invalid@invali d.invalidwrites :

On 11 Jun 2008 21:23:46 GMT, richard@cogsci. ed.ac.uk (Richard Tobin) wrote:
>

>>In article <1292858.4WXqv0 htDk@aioe.org>, Max <invalid@invali d.invalidwrote:
>>

>>>Can I ask C questions here?

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

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.

--
Ben.

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: Question

On Wed, 11 Jun 2008 23:16:11 +0000, Default User wrote:

Harald van Dijk wrote:

>On Wed, 11 Jun 2008 14:42:00 -0700, user923005 wrote:

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.

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