Hi,

The following code compiles fine with G++ 2.95.2 
& 2.96.

#include <iostream>
int  main()
{
        std::cout << "This causes Flexelint 
errors" << endl ;
        cout << "This works fine" << endl ;
}


Flexelint 8.00n is OK with it, but Flexelint 8.00n
gives
--- Module:   andy.cc
                  _
        std::cout << "This causes Flexelint 
errors" << endl ;
andy.cc  4  Error 40: Undeclared identifier 'cout'
andy.cc  4  Error 59: Bad type
andy.cc  4  Error 59: Bad type
andy.cc  4  Warning 522: Expected void type, 
assignment, increment or decrement

It probably has to do with this item in the 
release notes:

*   For gcc (option -cgnu) we have a special mode 
in which std::name
    (where name is any identifier) refers either 
to a name within
    namespace std or a name in the global 
namespace.  Instead of
    looking solely in the global namespace we 
were looking in all
    namespaces (unqualified name lookup) which 
opened the door to
    finding the wrong name.


Is there any way to block this behaviour in 8.00o
with an option?  I'd like to be able to move
to it for other reasons, but I have limited 
options in terms of source changes & compiler 
vintage.... 

Thanks in advance,
AndyG

Slight typo: 8.00o gives the indicated errors,
not 8.00n.

Hi, Andreas.
	Thank you for your report.  However, we 
failed to reproduce the problem here.  If 
possible, do send us a small sample reproducing 
the phenomenon.

Has there been any resolution to this issue?
I'm seeing the same on Ver 8.00p.
Manie

I ran into this problem as well for STL
namespaces. For example if I attempted to specify:

  std::vector<int> tempArray;

Flint would complain but not the compiler.
However, the same problem doesn't happen with

  vector<int> tempArray;

I could get around it by defining

  -d__STL_HAS_NAMESPACES

It's a special STL configuration flag (in our
version of it) used to specify whether the std
namespace should be used for STL.

Another possibly better solution is to make sure
the flint profiles contain the compiler version:

  -d__GNUC__=2 -d__GNUC_MINOR__=96

That's often how STL determines what version of
the compiler is running and whether std:: should
be added as a namespace.

Interestingly enough, the GNU compiler doesn't
seem to care about whether std:: is there or not.

Chris

Hi, Chris.
    You may find a significant number of surprises
in "Gcc 2.96", given the fact, according to
http://gcc.gnu.org/gcc-2.96.html, the 2.96
'Release' is not an official release.  May i
suggest upgrading to Gcc 3 or even 4?

Hi, Manie.
    We are still awaiting a reproducable sample.

I think this is the same problem an engineer 
reported in the group I'm in.  He had a great 
example that you can try as well as an ugly fix.  
We are using 8.00s:

****flintTest.h****
#include <vector>

class FlintTest
{
public:
   FlintTest();

private:
   std::vector<int> testVector_m;
};

****flintTest.cc****
#include <flintTest.h>

FlintTest::FlintTest() : testVector_m() {}

********************
FlexeLint messages:

--- Module:   flintTest.cc
              _
   std::vector<int> testVector_m;
./flintTest.h  9  Error 40: Undeclared 
identifier 'vector'
./flintTest.h  9  Warning 601: No explicit type 
for symbol 'FlintTest::__created', int assumed
                                     _
FlintTest::FlintTest() : testVector_m() {}
flintTest.cc  2  Error 40: Undeclared 
identifier 'testVector_m'
flintTest.cc  2  Note 1927: 
Symbol 'FlintTest::__created' did not appear in 
the constructor initializer list
flintTest.cc  2  Warning 1401: 
member 'FlintTest::__created' (line 9, 
file ./flintTest.h) not initialized by constructor

He was able to get rid of all the messages with 
the "using" command:

****flintTest.h****
#include <vector>

using std::vector;

class FlintTest
{
public:
   FlintTest();

private:
   vector<int> testVector_m;
};

****flintTest.cc****
#include <flintTest.h>

FlintTest::FlintTest() : testVector_m() {}

********************
FlexeLint messages:

--- Module:   flintTest.cc

I sent Frank this sample wrt. 8.00q, and again
with 8.00s.   It's still broken in 8.00t.

#include <iostream>
int  main()
{
        std::cout << "This causes Flexelint
errors" << endl ;
        cout << "This works fine" << endl ;
        return 0;
}


gives

flexelint co-gnu.lnt co-gnu-HPUX.lnt local.lnt
ofail.cc 
FlexeLint for C/C++ (U32) Vers. 8.00t, Copyright
Gimpel Software 1985-2005

--- Module:   ofail.cc (C++)
                  _
        std::cout << "This causes Flexelint
errors" << endl ;
ofail.cc  4  Error 40: Undeclared identifier 'cout'
ofail.cc  4  Error 59: Bad type
ofail.cc  4  Error 59: Bad type
ofail.cc  4  Warning 522: Expected void type,
assignment, increment or
    decrement

Personally, I haven't looked at this deeply, but has anyone tried 
using the option: 

+fsg

(the "Standard-namespace-is-an-alias-for-the-global-
namespace" flag)

...in their compiler options files?

Now, there's something you must be aware of when you send us 
code samples that begin with, e.g.: 

#include <iostream>

With that one preprocessor directive, this example has already 
become very large and murky.  Generally speaking (and with 
some very limited exceptions), its contents are unknown to us.  

When we start to talk about interesting non-Standard ways in 
which compiler "X" parses library code "Y", our understanding is 
not helped by your omission of library code "Y".  This is 
especially true of Standard library implementations.  All kinds of 
weird "black magic" (e.g., vendor-specific keywords, intrinsic 
functions, unusual constructs, etc.) may be employed therein.  
So whenever possible (e.g., when you have a license from the 
library vendor that says you are free to redistribute the library 
code, or whenever you have permission from the library vendor 
to send the code to us), please send us the preprocessor output 
generated by the compiler (use -E) and lint (use -p). 

I did send a preprocessed file to Frank when I
first reported the problem against 8.00o.   It
happened on our 2.95.2 Linux target as well.
( I'll send it again if you need it, but he
indicated that the problem had been replicated in
"Engineering" already )

FWIW, I tried +fsg and -fsg explicitly, and it made
no difference in the behaviour.    I don't see
this one documented anywere ... is there a plase
you've documented all the undocumented flags ??

The "fix" in 8.00o which seems to have broken the
behaviour is the following in the bugfix file:

*   For gcc (option -cgnu) we have a special mode
in which std::name
    (where name is any identifier) refers either
to a name within
    namespace std or a name in the global
namespace.  Instead of
    looking solely in the global namespace we were
looking in all
    namespaces (unqualified name lookup) which
opened the door to
    finding the wrong name.

I encountered the same bug today (warning 578
("...hides symbol ...").

I need -cgnu for soem of my sources, but is there
no way to disable the special handling of the
"std" namespace (except poking the right place i
a25.c) ?