Strange - a simple assignment statement shows error in VC++ but worksin gcc !

[Mateusz Loskot]

This is comp.lang.c, not comp.lang.c++. nullptr and new are C++ keywords;
they have no special meaning in C.

This is what happens when people don't understand why
cross-posting is evil!

Author of this thread sent it to these groups:
comp.lang.c, microsoft.public.vc.language

and C++ discussion is perfectly pm the latter.

I can only say sorry for myself.

Best regards,

 

[Keith Thompson]

Only that last example was C++, and it's *not* off-topic. It's an
example that's helpful to illuminate the difference in behavior
between MSVC and GCC. These same difference also manifest in C code.
If an example from another language helps to understand a C language
construct or tool, it is most definitely on topic for c.l.c.

You might have a point if you can provide C code that illustrates the
same point.

Upthread, you mentioned this code:

if(!FunctionThatNowReturnsInt(x))
{
// process error
}

and said something to the effect that MVC issues a warning about an
implicit conversion from int to bool. If the code is C, there is no
such conversion; the "!" operator takes an int argument and yields an
int result, and the if expects an expression of any scalar type. If
MVC issues a warning and gcc doesn't, it's because they're compiling
different languages. This code, and MVC's warning do not illustrate
anything about C; it's purely a C++ issue.

Later, you posted the following:

| template <typename T> static void numtostring(T n, char *buf)
| {
| if(n<0)
| {
| *buf++='-';
| n=-n;
| }
| // ...
| }
|
| MSVC issues a warning when the class is instantiated with an unsigned
| type. Clearly, the 'if' code is is a safe no-op for unsigned classes
| and intended to do the right thing for signed classes.

Again, if you want to make a point about C, you can do so by posting
an example in C. You could probably turn the above into a C program
that illustrates something similar.

 

[Kenny McCormack]

You (DS, not KS) are wrong on so many counts, but I'm not going to
enumerate them.

But I love it when regs fight...
(Better than watching chicks fight)

 

[CBFalconer]

.... snip ...

Sorry, I should have been clearer. I wasn't asking how you thought
the code works; I was wondering how you thought the C++ keyword
'new' works. If you were under the impression that correct use of
'new' produced an expression with a 'void' type, how did you
imagine that C++ code gained access to the object being allocated?

I'm an atavist. I don't use C++. I had the impression its new
worked like the Pascal version. I.E:

new(&pointertosomething);

generates a value for pointertosomething (or NULL for failure).

 

[CBFalconer]

No. That is a mindless reflex that is both irritating and harmful.

The point is that that code (which you snipped) is not C, therefore
if compiled on VC++ it was not compiled as C source. Therefore it
doesn't belong on c.l.c. It is probably acceptable on c.l.c++.

 

[Default User]

The point is that that code (which you snipped) is not C, therefore
if compiled on VC++ it was not compiled as C source. Therefore it
doesn't belong on c.l.c. It is probably acceptable on c.l.c++.

Why does comp.lang.c topicality override microsoft.public.vc.language
topicality?

We're right to restrict things posted solely to our group, but you have
to be cognizant of the cross-posting. If people wanted to be strict,
they should have removed the cross at the beginning.





Brian

 

[James Kuyper]

James Kuyper wrote:
... snip ...

I'm an atavist. I don't use C++. I had the impression its new
worked like the Pascal version. I.E:

new(&pointertosomething);

generates a value for pointertosomething (or NULL for failure).

If you're that poorly informed about how C++ works, I recommend avoiding
making comments like "Is it even C++?". I think you can reasonably
assume that anybody who posts C++ code on comp.lang.c in the mistaken
belief that such code is on-topic here, probably knows far more about
C++ than you do, despite being clueless about the difference between C
and C++.

 

[CBFalconer]

If you're that poorly informed about how C++ works, I recommend
avoiding making comments like "Is it even C++?". I think you can
reasonably assume that anybody who posts C++ code on comp.lang.c
in the mistaken belief that such code is on-topic here, probably
knows far more about C++ than you do, despite being clueless
about the difference between C and C++.

I don't care if he knows more about C++ than I do. I do care that
he is posting C++ code on c.l.c, and it is not an idle post. His
question was about the C++. It was, and is, off-topic. My
original post simply advised him of this topicality problem.

 

[David Schwartz]

The point is that that code (which you snipped) is not C, therefore
if compiled on VC++ it was not compiled as C source.  Therefore it
doesn't belong on c.l.c.  It is probably acceptable on c.l.c++.

This is not the rule. It is perfectly acceptable on c.l.c to
illuminate a C-language point with a non-C-language example. It would
be preferable to use a C-language example if possible, but in this
case, no C-language example is known.

Certainly, asking something like "What is the C language equivalent of
'LET i=i+1'?" is on topic for c.l.c. (though trivial). The fact that
the post happens to contain BASIC code doesn't mean it isn't about C.

The question is, what is the post *ABOUT*, not how does it make its
point. The post is about differences in the warnings issued by GCC and
MSVC. Very few examples are known, and seeing C++ examples may help to
find more C examples.

DS

 

[David Schwartz]

Again, if you want to make a point about C, you can do so by posting
an example in C.  You could probably turn the above into a C program
that illustrates something similar.

Actually, I couldn't do so by posting an example in C. I didn't have
one.

I believe you are right, and it can be turned into a C program that
illustrates something similar. That's why it's on-topic for c.l.c.

It illustrates a point that is relevant to the C language, and I have
no way to express it in C.

It is as on-topic as "what's the C equivalent of 'LET A=A+1'".

DS

 

[David Schwartz]

Do you have an example where adding a cast to perfectly legal code
silences a warning?

unsigned j;
int64_t q;

j=q;

This is perfectly legal code. MSVC, with appropriate settings, will
issue a warning.

Someone looking over this code will not immediately know whether or
not the original programmer realized that there was a conversion here.
Adding a cast makes it clear that you understand that a conversion
will take place and that you know that it is safe.

Changing the code to "j=(unsigned)q;" make it clear to anyone looking
(and to the compiler) that the programmer knew that there was a
conversion here.

The biggest disadvantage to doing this is that if the type of 'j' is
ever changed, the code may now be wrong.

I do not believe GCC will issue a warning unless '-Wconversion' is
specified. The normal things like '-Wall' and '-Wextra' will not cause
a warning in this case. (And I'm not arguing that's a bad decision.)

DS

 

[Rainer Weikusat]

unsigned j;
int64_t q;

j=q;

This is perfectly legal code. MSVC, with appropriate settings, will
issue a warning.

Someone looking over this code will not immediately know whether or
not the original programmer realized that there was a conversion here.
Adding a cast makes it clear that you understand that a conversion
will take place and that you know that it is safe.

Changing the code to "j=(unsigned)q;" make it clear to anyone looking
(and to the compiler) that the programmer knew that there was a
conversion here.

If anything, this makes it 'clear' that 'the programmer' didn't knew
how assignments to unsigned integer objects are supposed to work in C,
and consequently, requested that the compiler performs a conversion it
is actually required to perform in any case.

 

[Keith Thompson]

unsigned j;
int64_t q;

j=q;

This is perfectly legal code. MSVC, with appropriate settings, will
issue a warning.

Someone looking over this code will not immediately know whether or
not the original programmer realized that there was a conversion here.
Adding a cast makes it clear that you understand that a conversion
will take place and that you know that it is safe.

Changing the code to "j=(unsigned)q;" make it clear to anyone looking
(and to the compiler) that the programmer knew that there was a
conversion here.

My first assumption on seeing such a statement (in the absence of your
explanation) would be that the programmer didn't know C very well, and
mistakenly thought that the cast was necessary, or perhaps that the
cast was added just to silence a warning.

Since "j=q;" and "j=(unsigned)q;" (given the above declarations) mean
exactly the thing, a compiler could conceivably warn about both of
them, or just about the version with the cast.

The best way to make it clear that you know the conversion is safe is
to add a comment: /* This conversion is safe. */.

The biggest disadvantage to doing this is that if the type of 'j' is
ever changed, the code may now be wrong.

I agree that that's the biggest advantage, but it's not the only one.

[...]

 

[David Schwartz]

If anything, this makes it 'clear' that 'the programmer' didn't knew
how assignments to unsigned integer objects are supposed to work in C,
and consequently, requested that the compiler performs a conversion it
is actually required to perform in any case.

Even if that's true, that's harmless. It still communicates that the
programmer *intended* the conversion. That's really all that's
important. The reviewer doesn't really care how good or bad the
programmer was, he just cares that the program does what the
programmer intended and what the specifications call for.

DS

 

[David Schwartz]

My first assumption on seeing such a statement (in the absence of your
explanation) would be that the programmer didn't know C very well, and
mistakenly thought that the cast was necessary, or perhaps that the
cast was added just to silence a warning.

That's fine. Both of those things still communicate the essential
facts, which is that the programmer knew that the conversion would
occur and intended it.

Since "j=q;" and "j=(unsigned)q;" (given the above declarations) mean
exactly the thing, a compiler could conceivably warn about both of
them, or just about the version with the cast.

Why would it warn about the cast? No compiler warns about that cast --
it does exactly what the programmer obviously expected. The problem
with "j=q;" is that there is no way to know that the programmer
*intended* the conversion.

If you have any large, complex project and run without conversion
warnings enabled, enable them sometime. If you find, say, 300
warnings, I will bet you that at least 1/4 of them will be cases where
you didn't realize a cast was involved. The vast majority of those, of
course, will be safe.

The best way to make it clear that you know the conversion is safe is
to add a comment: /* This conversion is safe. */.

Comments should only be used where it's either not possible or
significantly inferior to make the code self-commenting. In this case,
the cast makes the code self-commenting. So unless you have a case
where the cast is significantly inferior, it's preferable to cast than
comment. Another advantage is that automated testing tools are much
more likely to understand the cast than the comment.

I agree that that's the biggest advantage, but it's not the only one.

I presume you meant disadvantage. And I agree. This is not always
unequivocally better. Some warnings can only be silenced with code so
ugly you would be wise to live with the warning instead.

FWIW, I just took a 190,000 line commercially-deployed, well-audited
application and spent an hour analyzing conversion warnings. There
were 1,396 conversion warnings and I analyzed about 250 of them. Of
them, the vast majority (90% or so) were obviously harmless.

Quite a few of them (15 or so) revealed aspects of the code that were
clearly not thought about, but turned out to be safe. These required
some changes to ensure the code was completely solid. Adding a cast
was not sensible here, as it would suggest we know the cast is safe.
But I don't believe any of my changes on these would have any actual
effects on the code's operation.

There were six actual bugs, most nearly harmless. (Which probably
explains why they weren't caught.)

The one that had the most obvious serious consequence caused an
incorrect call to 'posix_fadvise' claiming random access (rather than
the intended sequential) for files that are part of an FTP-like file
transfer system. I believe this will, at least on some OSes, disable
read ahead.

Catching six bugs an hour in well-audited, deployed code is pretty
darn good.

DS

 

[Chris Ahlstrom]

After takin' a swig o' grog, David Schwartz belched out
this bit o' wisdom:

FWIW, I just took a 190,000 line commercially-deployed, well-audited
application and spent an hour analyzing conversion warnings. There
were 1,396 conversion warnings and I analyzed about 250 of them. Of
them, the vast majority (90% or so) were obviously harmless.

Quite a few of them (15 or so) revealed aspects of the code that were
clearly not thought about, but turned out to be safe. These required
some changes to ensure the code was completely solid. Adding a cast
was not sensible here, as it would suggest we know the cast is safe.
But I don't believe any of my changes on these would have any actual
effects on the code's operation.

There were six actual bugs, most nearly harmless. (Which probably
explains why they weren't caught.)

The one that had the most obvious serious consequence caused an
incorrect call to 'posix_fadvise' claiming random access (rather than
the intended sequential) for files that are part of an FTP-like file
transfer system. I believe this will, at least on some OSes, disable
read ahead.

Catching six bugs an hour in well-audited, deployed code is pretty
darn good.

And you will be able to find more bugs or loose code in any project,
even after many passes over it.

 

[Martin Ambuhl]

Comments should only be used where it's either not possible or
significantly inferior to make the code self-commenting. In this case,
the cast makes the code self-commenting.

This is, of course, just silly. The completely superfluous cast is
_nothing_ other than a comment. To disguise a comment as "code" is a
very bad idea.

Since <comp.os.linux.advocacy> has nothing to do with this thread, I
have removed it. Even though it is unlikely that the thread is relevant
to <comp.os.linux,development.apps>, I don't know that for sure and have
left it. I apologize to people in that newsgroup if it appears that we
are polluting it.

 

[Rainer Weikusat]

Even if that's true, that's harmless.

It's the only possible conclusion from the code which neither
assumes malice nor gross incompetence on part of the original code
author, ie neither did he purposely write useless text, say, 'because
it was hard to write, it should be hard to read' or in order to help
with 'making something out of nothing' nor did he just copy&paste it
from elsewhere, changing as little as possible for fear of otherwise
breaking something.

It still communicates that the programmer *intended* the conversion.

It communicates that someone wrote (unsigned) for some reason and that,
taking the semantics of C into account, this was a reason of a
non-technical nature, ie a magic incantation intended placate some
Cerberus on the way to elysium, such as a code reviewer known to
enforce random, aesthetic preferences of his own.

If 'programmer writing code which converts' is not sufficient to
assume 'programmer intended conversion', 'programmer writing
$anything' is technically not sufficient to assume that 'programmer
wanted to write $thing' or 'programmer should have written this
$thing' --- which is the actual problem: It doesn't matter the least
what the person who wrote the code intended to write. What matters is
what he wrote and if this works as it should work. In particular, in
case of any type of programming error, what the author intended to
write is not what should have been written.

 

[Joe Pfeiffer]

If anything, this makes it 'clear' that 'the programmer' didn't knew
how assignments to unsigned integer objects are supposed to work in C,
and consequently, requested that the compiler performs a conversion it
is actually required to perform in any case.

It makes it clear that the programmer knew a conversion had to take
place.

Any inferences regarding the competence of the programmer depend on
context.

 

[Richard Tobin]

It communicates that someone wrote (unsigned) for some reason and that,
taking the semantics of C into account, this was a reason of a
non-technical nature, ie a magic incantation intended placate some
Cerberus on the way to elysium, such as a code reviewer known to
enforce random, aesthetic preferences of his own.

It might communicate that to you, but it wouldn't communicate it to
me. For a programmer to assume that his readers are like you in this
respect is probably a mistake.

-- Richard