Board index » cppbuilder » Re: BDS2006 include bug

Re: BDS2006 include bug


2006-02-08 07:29:30 PM
cppbuilder101
Russell Hind wrote:
Quote
We have a header file named Math.h in a folder that has to be on our
include paths.

This path is added below the $(BDS)\include and
$(BDS)\include\dinkumware headers but a call to #include <math.h>
still seems to find it. This wasn't the case with BCB6 and shouldn't
be the case now.
To clarify:
You are including the standard C header <math.h>but finding your own
math.h instead? And to fix the bug, BCB2006 should find the Standard
header?
--
AlisdairM(TeamB)
 
 

Re:Re: BDS2006 include bug

(project posted to .attachments)
We have a header file named Math.h in a folder that has to be on our
include paths.
This path is added below the $(BDS)\include and
$(BDS)\include\dinkumware headers but a call to #include <math.h>still
seems to find it. This wasn't the case with BCB6 and shouldn't be the
case now. We currently can't build our projects unless we can come up
with a work-around other than re-naming a load of our files. The
command-line from BDS shows the include paths being passed to the
compiler correctly but the compiler is behaving incorrectly.
The command-line is
C++ command line for "Unit1.cpp"
-D_DEBUG -D_RTLDLL;NO_STRICT;_NO_VCL -H="c:\program
files\borland\bds\4.0\lib\vcl100.csm" -Hc -w-par -Od -b- -k -y -v -vi-
-tWC -tWM -tW- -c
-I"c:\program files\borland\bds\4.0\include";"c:\program
files\borland\bds\4.0\include\dinkumware"
C:\Users\Russell.Hind\Projects\BDS2006\TPICoatingScan\Source\BDSTest\Shared;"c:\program
files\borland\bds\4.0\Include\Indy10";"c:\program
files\borland\bds\4.0\Lib\Indy10";"C:\Program
Files\Borland\BDS\4.0\RaveReports\Lib"
-oC:\Users\Russell.Hind\Projects\BDS2006\TPICoatingScan\Source\BDSTest\Debug_Build\Unit1.obj
But pre-processing Unit1.cpp gives the correct output. So is the IDE
lying about the order of the include paths sent to the compiler or is
the compiler processing them incorrectly.
Any help would be greatly appreciated.
Cheers
Russell
 

Re:Re: BDS2006 include bug

Russell Hind wrote:
Quote
No, have a look at the project. I'm including <cmath>. It includes
<math.h>and finding mine before the standard one, which it shouldnt'.
OK, I have taken another read of ISO Chapter 17 to confirm my details -
and think I might have another defect report for the standard ;?
But from my reading:
#include <math.h>can only ever mean the Standard C header file, as
provided by Appendix D, although deprecated.
This standard header must be found, by whatever means, regardless of
the environment you perform the build in.
There are 'undefined behaviour' escape clauses, but they only apply for
'free-standing' implementations, not a 'hosted implementation' like BCB.
Looks like a genuine bug to me.
All that aside, it would be much nicer for all concerned if you did not
have files with the same name as Standard headers{*word*154} around your
build tree ;? I am aware how hard this sort of problem can be to fix
though.
--
AlisdairM(TeamB)
 

{smallsort}

Re:Re: BDS2006 include bug

Russell Hind wrote:
Quote
FWIW, as mentioned, if I pre-process the file in the IDE, it finds
the correct math.h so it is just when compiling.
That is an interesting bug report in its own right - proprocessing
SHOULD produce the same token stream the compiler sees, or it is no
longer a useful diagnostic aid.
Are you writing any of these up in QC? If so I'll take a look to see
if I can Open the reports tonight.
--
AlisdairM(TeamB)
 

Re:Re: BDS2006 include bug

AlisdairM wrote:
Quote

To clarify:
You are including the standard C header <math.h>but finding your own
math.h instead? And to fix the bug, BCB2006 should find the Standard
header?

No, have a look at the project. I'm including <cmath>. It includes
<math.h>and finding mine before the standard one, which it shouldnt'.
Cheers
Russell
 

Re:Re: BDS2006 include bug

Russell Hind wrote:
Quote

No, have a look at the project. I'm including <cmath>. It includes
<math.h>and finding mine before the standard one, which it shouldnt'.

Wouldn't be an issue if QC #10783 was fixed as we wouldn't need our
folders added as include paths but the IDE forces this for any folder
that contains a .cpp file added to the project. We include ours via
"Shared/Math.h".
Cheers
Russell
 

Re:Re: BDS2006 include bug

AlisdairM wrote:
Quote

All that aside, it would be much nicer for all concerned if you did not
have files with the same name as Standard headers{*word*154} around your
build tree ;? I am aware how hard this sort of problem can be to fix
though.

I completely agree but BCB6 doesn't have this problem so something has
been broken and we include them via there parent folder such as
#include "Shared/Math.h"
So shouldn't ever have a conflict.
Regarding standards though, given the order of the include paths, then
cmath should never find our Math.h over <math.h>because it should start
searching the include paths in the order they are listed which means it
will find its first.
This looks like BDS is searching them in reverse order from that specified.
FWIW, as mentioned, if I pre-process the file in the IDE, it finds the
correct math.h so it is just when compiling.
Cheers
Russell
 

Re:Re: BDS2006 include bug

This is a known bug that Borland/Owen is looking into.
The workaround that I've found is to change the path so that
it shows "c:\progra~1\Borland\bds\4.0" rather than
"c:\program files\Borland\bds\4.0"
This has made my embedded test app work properly.
HTH Pete
"AlisdairM" < XXXX@XXXXX.COM >wrote in message
Quote
Russell Hind wrote:

>FWIW, as mentioned, if I pre-process the file in the IDE, it finds
>the correct math.h so it is just when compiling.

That is an interesting bug report in its own right - proprocessing
SHOULD produce the same token stream the compiler sees, or it is no
longer a useful diagnostic aid.

Are you writing any of these up in QC? If so I'll take a look to see
if I can Open the reports tonight.
 

Re:Re: BDS2006 include bug

Pete Fraser wrote:
Quote
This is a known bug that Borland/Owen is looking into.
The workaround that I've found is to change the path so that
it shows "c:\progra~1\Borland\bds\4.0" rather than
"c:\program files\Borland\bds\4.0"
This has made my embedded test app work properly.

Yes, that fixed it thanks. So bcc32 doesn't like paths with spaces in
anymore? Doesn't look good given $(BDS) defaults to C:\Program
Files\Borland\BDS\4.0!
Cheers
Russell
 

Re:Re: BDS2006 include bug

AlisdairM wrote:
Quote

Are you writing any of these up in QC? If so I'll take a look to see
if I can Open the reports tonight.

I will do when I get a chance. Only just installed BDS today though!
Cheers
Russell
 

Re:Re: BDS2006 include bug

Nope it's not down to spaces, they aren't a problem.
I think the compiler has some predefined include paths
built in and if it finds these, it ignores your path order
(to some extent - a very simplistic definition)
Rgds Pete
"Russell Hind" < XXXX@XXXXX.COM >wrote in message
Quote
Pete Fraser wrote:
>This is a known bug that Borland/Owen is looking into.
>The workaround that I've found is to change the path so that
>it shows "c:\progra~1\Borland\bds\4.0" rather than
>"c:\program files\Borland\bds\4.0"
>This has made my embedded test app work properly.
>

Yes, that fixed it thanks. So bcc32 doesn't like paths with spaces in
anymore? Doesn't look good given $(BDS) defaults to C:\Program
Files\Borland\BDS\4.0!
 

Re:Re: BDS2006 include bug

In article <43e9e692$ XXXX@XXXXX.COM >,
Russell Hind < XXXX@XXXXX.COM >wrote:
Quote
No, have a look at the project. I'm including <cmath>. It includes
<math.h>and finding mine before the standard one, which it shouldnt'.
This sounds similar to this QC report:
<qc.borland.com/wc/qcmain.aspx>
Do you think they are related?
--
-David
Nihil curo de ista tua stulta superstitione.
 

Re:Re: BDS2006 include bug

Pete Fraser wrote:
Quote
Nope it's not down to spaces, they aren't a problem.
I think the compiler has some predefined include paths
built in and if it finds these, it ignores your path order
there is bcc32.cfg in the $(BDS)\bin folder that defines paths. I think
it takes precedence (or at least mucks around with your settings).
.a
 

Re:Re: BDS2006 include bug

There is something else as well as my bcc32.cfg doesn't affect the bug :(
Anyway Borland know about it and are working for a fix. (I hope)
Rgds Pete
"Alex Bakaev [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
Pete Fraser wrote:
>Nope it's not down to spaces, they aren't a problem.
>I think the compiler has some predefined include paths
>built in and if it finds these, it ignores your path order

there is bcc32.cfg in the $(BDS)\bin folder that defines paths. I think it
takes precedence (or at least mucks around with your settings).
 

Re:Re: BDS2006 include bug

Pete Fraser wrote:
Quote
Nope it's not down to spaces, they aren't a problem.
I think the compiler has some predefined include paths
built in and if it finds these, it ignores your path order
(to some extent - a very simplistic definition)
Rgds Pete

It is odd though that our include paths in the project are
$(BDS)\include
$(BDS)\include\dinkumware
Shared
The IDE reports that is is passing to the compiler during build
c:\program files\borland\bds\4.0\include
c:\program files\borland\bds\4.0\include\dinkumware
C:\Users\Russell.Hind\Projects\BDS2006\TPICoatingScan\Source\BDSTest\Shared
c:\program files\borland\bds\4.0\Include\Indy10
c:\program files\borland\bds\4.0\Lib\Indy10
C:\Program Files\Borland\BDS\4.0\RaveReports\Lib
which isn't correct because any code (either in our code or in
dinkumware headers etc) that does a
#include <math.h>
is finding our math.h in Shared, rather than in the system paths.
And in bcc32.cfg:
C:\Program Files\Borland\BDS\4.0\Include
C:\Program Files\Borland\BDS\4.0\Include\vcl
C:\Program Files\Borland\BDS\4.0\Include\dinkumware
C:\Program Files\Borland\BDS\4.0\include\Indy10
which explains where it is getting the Indy10 from which was confusing
me, but not where it is picking ravereports that is being passed to the
compiler.
But I've just removed bcc32.cfg and re-started the IDE, but it is still
passing the same set of paths to the compiler so it doesn't look like
its picking them up from that.
Cheers
Russell