 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The following is an excerpt from express.c
(MegaPov 0.6a, lines 505 and below):
if( hfield->Type & HFIELD_OBJECT != HFIELD_OBJECT )
Error( "Cannot find height of non-height-field.\n" );
if( ( Val < 0 ) || ( Val2 < 0 ) ||
( Val > 1 ) || ( Val2 > 1 ) )
Error( "Height-field index out of bounds [0 1].\n" );
Since the precedence of 'not equal' is higher than that
of 'bitwise and', the very first line really means
if( hfield->Type & 0 )
and thus the error message never appears. In fact,
optimizing compilers eliminate entire statement. I
quoted a little bit more than necessary just to illustrate
(and rant :-) how... unwise people use parentheses.
BTW (to those who are interested): this strange
precedence rule goes deep into the history of C...
From the very beginning, there were no such things
as 'logical and' and 'logical or' (that is, '&&' and '||'),
the only 'and' and 'or' operators were '&' and 'I',
respectively, serving as either logical or bitwise
based upon context ("truth-value-context"). When
their "pure logical" counterparts were introduced,
K&R were forced to stick with their current
precedence to maintain compatibility with existing
code.That's that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A good compiler would issue a warning there (because the condition is
always false) and the bug would have been located immediately.
However, as the POV-Ray source code issues about 10000 warnings I suppose
that no-one has full warnings turned on in their compilers (or if they have,
this specific warning gets buried under all the other 9999 ones).
Warnings are always important and they shouldn't be taken lightly. This
ideology has not been followed in POV-Ray.
Fortunately now that POV-Ray will be written in C++ it will be possible to
completely get rid of all warnings (C++ allows getting rid of certain
warnings the C version has and you can't do anything about it: Unused function
parameters: Just don't give the parameter a name).
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b6d2f36@news.povray.org> , Warp <war### [at] tag povrayorg> wrote:
> A good compiler would issue a warning there (because the condition is
> always false) and the bug would have been located immediately.
> However, as the POV-Ray source code issues about 10000 warnings I suppose
> that no-one has full warnings turned on in their compilers (or if they have,
> this specific warning gets buried under all the other 9999 ones).
This bug is actually one of the many code quality problems in MegaPOV. A
good developer should know which warnings are informative and which are more
like non-fatal errors. Turn off the float-double conversion warning and you
get only very few warnings.
For example, would you consider the legal code ISO C/C++ "long I = 'abcd';"
worth a (by default on) warning? Well, the gcc developers think so...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b6c959e@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:
> The following is an excerpt from express.c
> (MegaPov 0.6a, lines 505 and below):
This particular feature will probably be removed in future versions of
MegaPOV as it is not part of POV-Ray 3.5. The suggested method is to use
"trace".
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote in message
news:3b6d4886@news.povray.org...
> In article <3b6d2f36@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
>
> For example, would you consider the legal code ISO C/C++ "long I =
'abcd';"
> worth a (by default on) warning?
Yes, definitely. Although it's legal, it is implementation-defined
(i.e. the characters are mapped into the execution character set
in the implementation-defined manner). BTW, that's the reason
behind the MKFOURCC macro in Windows.h.
That's especially important for POV-Ray. Just imagine porting code with
that constant to, say, ancient Honeywell Bull with 36-bit chars...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b6d6d58@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:
> Yes, definitely. Although it's legal, it is implementation-defined
Exactly that is my point. It isn't the business of the compiler to lecture
the programmer about the language definition in such a case. It is clearly
specified as resulting in an implementation defined integer constant. This
is a well-defined behavior and if the programmer isn't aware of it, i.e. by
doing a comparison like 'abcd' > 1234 it is at least very bad style (nearly
programming error). However, declaring i.e. an enumeration with
multicharacter constants is fine, after all comparing an enumeration value
against an integer constant is bad style.
So why should a compiler issue a warning about something that is absolutely
legal? Well, the simple answer is that it should shut up by default and
assume the programmer knows the standard. A compiler should not assume an
incompetent programmer by default - and a multicharacter constant can hardly
be considered accidental. Or should a compiler warn i.e. in a case like
"int i = 01;" because the programmer might have meant to write "0"? If i
write a multicharacter constant I mean it, and it is a perfectly legal
program on every platform, thus the compiler does no need to "comment" it.
> That's especially important for POV-Ray. Just imagine porting code with
> that constant to, say, ancient Honeywell Bull with 36-bit chars...
So because some stoneage non-standard hardware and software it has to be on
on every 32 and 64 bit processor? I like that ... after all there is
nothing wrong with a character constant on a 36 bit system. Of course it
would be different if the resulting value would not _fit_ into an "int".
But obviously a four character constant fits will into a "int" on every 32+
bit system. On a system with 16 bit "int"s it would of course be
appropriate if the compiler would issue an error (or warning) if a constant
is out of range!
On the other hand, to force the programmer to use tricks to get the compiler
to shut up is far more dangerous and leads to bloated and unreadable code.
The programmer is the master of the compiler*, not the other way around!!!
Thorsten
* IMO, very ambiguous code should be considered an error and there would be
no default warnings at all in a really good C/C++ compiler. Of course, a
well-specified and implemented language would not have such problems in the
first place <sigh>
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> A good compiler would issue a warning there (because the condition is
> always false) and the bug would have been located immediately.
> However, as the POV-Ray source code issues about 10000 warnings I suppose
> that no-one has full warnings turned on in their compilers (or if they have,
> this specific warning gets buried under all the other 9999 ones).
>
> Warnings are always important and they shouldn't be taken lightly. This
> ideology has not been followed in POV-Ray.
> Fortunately now that POV-Ray will be written in C++ it will be possible to
> completely get rid of all warnings (C++ allows getting rid of certain
> warnings the C version has and you can't do anything about it: Unused function
> parameters: Just don't give the parameter a name).
POV gives about 10000 warnings on what warning level? I keep my copy of
msvc on level 3. On level 4 (highest) I get tons of crap I don't care
about like "assignment in conditional expression." I know, that's what
I want! On level 3 though I always try to get rid of the warning
messages my code makes.
But then, is msvc a "good compiler"? ;)
(ya know, like "if( !(fil = fopen(...)) )")
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In povray.unofficial.patches Thorsten Froehlich <thorsten@trf.de> wrote:
: Or should a compiler warn i.e. in a case like
: "int i = 01;" because the programmer might have meant to write "0"?
Actually 01 is an octal number ;)
(In fact, that's another place where you can shoot yourself in the foot
with C. You might sometimes write something like "i = 011;" to "indent" the
number with other similar numbers and then you are surprised when the
program behaves very strangely...)
This is actually one place where the compiler assumes that the user
really wanted an octal number and that it wasn't just a mistake.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Aug 2001 19:58:32 -0400, Warp wrote:
>In povray.unofficial.patches Thorsten Froehlich <thorsten@trf.de> wrote:
>: Or should a compiler warn i.e. in a case like
>: "int i = 01;" because the programmer might have meant to write "0"?
>
> Actually 01 is an octal number ;)
and is distinct from 0l.
--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b6ddda7@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Actually 01 is an octal number ;)
>
> (In fact, that's another place where you can shoot yourself in the foot
> with C. You might sometimes write something like "i = 011;" to "indent" the
> number with other similar numbers and then you are surprised when the
> program behaves very strangely...)
>
> This is actually one place where the compiler assumes that the user
> really wanted an octal number and that it wasn't just a mistake.
Exactly. And in my example (unlike 011) it wouldn't even make a difference
if one wrote 01 or 1. So why does it make a difference if I write 'ab'? --
Both are features of the language. They are both a bit "unexpected", but
still perfectly legal!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
