Forte 6U2 C++ compiler bug

In the Forte 6U2 compiler, a function return can implicitly invoke a conversion constructor that is marked "explicit".
Consider:
class ABaseClass {};
template<class Type, class Uncert>
class Value
public:
     Value(Type const& t, Uncert const& u) : _t(t), _u(u) {}
protected:
     Type       _t;
     Uncert    _u;
class Foo : public Value<float, double>, public ABaseClass
public:
     explicit
     Foo(ABaseClass b=ABaseClass(), float val=-1, double tol=0)
         : ABaseClass(b), Value(val, tol)
         std::cerr << "Explicit constructed Foo\n";
class Bar : public Value<int, double>, public ABaseClass
public:
     explicit
     Bar(ABaseClass b=ABaseClass(), int val=-1, double tol=0)
         : ABaseClass(b), Value(val, tol)
         std::cerr << "Explicit constructed Bar\n";
class Context
public:
     Context() : _foo(ABaseClass(), 1.23, 0.45) {}
     Bar getFoo() const
         return _foo;
private:
     Foo _foo;
int main()
     Context c;
     c.getFoo();
}Note that Context::getFoo has a type mismatch between the declared return type and the return value. This is a bug that was not caught by the compiler. Intstead, Bar(static_cast<ABaseClass>(_foo)) is invoked and
returned. The output of this run is:
Explicit constructed Foo (Context constructor)
Explicit constructed Bar (Context::getFoo return)
This behavior is non-standards conforming.

-xO2 is enough to cause the failure.
Making the vulnerable pointer "static" fixes the problem, although this should make no difference.
My guess is over-eager register reuse, but I'm open to alternative theories.

Similar Messages

  • Forte 6u1 C compiler bug?  Worse in 6u2?

    I have a rather large program containing a function which misbehaves intermittently with -xO3 optimization. The failure occurs on perhaps one run in ten.
    A pointer variable local to the function appears to be corrupted by a call to another function. (It's ok before, and bad after the call.) The corrupted pointer value then usually causes a BUS error, rarely a SEGV (depending on its divisibility by 8, I assume).
    Adding printf() calls showed the corrupt value (lately, 0x800000002 has been popular) using 6u1. After updating to 6u2, the intermittent corruption remains, but now the printf() itself fails, as it apparently tries to dereference the pointer (for some mysterious reason) instead of just displaying it. Dbx (6u2) says:
    Read from unallocated (rua):
    Attempting to read 1 byte at address 0x800000002
    stopped in _doprnt at 0x7fef5189d54
    0x000007fef5189d54: doprnt+0x0160:     ba,a    doprnt-0xda41c
    (/opt/forte6u2/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
    =>[1] _doprnt(0x100327630, 0xffffffff7fffefc0, 0x100327630, 0xff291400, 0x0, 0x0), at 0x7fef5189d54
    [2] _fprintf(0x0, 0x800000002, 0x7fef52be228, 0x0, 0xffffffffffffffff, 0x100327db0), at 0x7fef518d088
    [3] <my_stuff ...>
    The (newly) offending statement looks like this:
    fprintf( pfCFile, " a = %016lx.\n", assign);
    where "assign" is the pointer to a structure of some sort.
    Does anyone have any helpful hints or will I need to spend the $1599 to create an incident?

    -xO2 is enough to cause the failure.
    Making the vulnerable pointer "static" fixes the problem, although this should make no difference.
    My guess is over-eager register reuse, but I'm open to alternative theories.

  • Patch problem with Forte 6U2?

    I just installed all of the patches currently up at access1 for Forte 6U2 on solaris 8. When I rebuilt, I got the following
    Error: The destructor name must match the class name.
    while building the following code fragment:
       template<typename T>
       class table
          class node {
          public:
                   explicit
             node(const T&);
             ~node();
                  // ... other stuff
          // ... other stuff
       // much later in same header
              template<typename T>
              inline
        table<T>::node::~node()
        }The error occurs on the out-of-body inline delcaration of table<T>::node::~node() above.
    This code compiled fine with previous patches, and works correctly under gcc3.1 and gcc3.2.
    CC -v gives me:
    CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-10 2002/09/16
    Any information would be appreciated.
    Thanks.

    I think you and I have different definitions of "status".
    Search Failed == Not Fixed seems like a pretty coarse status measurement to me, and a poor interface to boot. If I had a support contract, would I actually be able to read a description of the bug as it is currently filed from suns perspective? What could possibly be so expensive about giving read access to an existing defect database ( esp. when compared with the cost of fixing defects ) that you need to charge to underwrite it? Does it not strike you as almost punitive to require payment from those users who found, tested, and submitted defects for the right to track the status of those defects? Please, please, please explain the rationale behind this to me. I find the whole approach infuriating, unnecessarily opaque, and counterproductive.
    Am I interested in finding out that the defect is fixed. Yes. But what is far more important to me is to know that you are actually doing something about it. This critical piece of information is sorely lacking in the current system, especially given the number of defects I have submitted, which were assigned bug IDs, but which have never been fixed in any patch.
    http://sunsolve.sun.com is the website you could check
    the status of the bug. Search for the bug ID, if it's
    not found, then the patch for it is not released.
    Otherwise, you will see the patch ID. I don't think
    you need to have contract to surf the website.
    - Rose

  • Forte 6U2 - poor performance of std::map::operator[]

    I discovered to my horror this morning that Forte 6U2 implementation of std::map (at least at the patch level I'm working with) ALWAYS default constructs a value_type when operator[] is invoked - even if value_type already exists in the map.
    Any reasonable STL implementation first uses lower bound to search, and failing to find an appropriate element, uses the resulting iterator as an insertion hint, only then default constructing a value_type (and therefore a mapped_type) element.
    The existing implementation in Forte 6U2 imposes an absurd penalty on the use of the subscript operator when mapped_type's default construction semantics are non-trivial. While "correct" in the sense that the contract for std::map::operator[] is met, I cannot imagine that this was an intentional design choice given the performance implications. How can I get this issue addressed?

    Well, I wasn't making any claim about the efficiency of the underlying tree representation - only the fact that operator[] unconditionally default constructs a mapped_type object, even if there is already an appropriate element in the map, which is no good at all. I'll try your request for enhancement thing though...
    While I would very much like to switch to using STLport vs. the RW stl, a compiler upgrade is not the answer here.

  • Problem with variadic macros, Forte 6U2

    The following code demonstrates a problem with namespace qualifiers used in variadic macros. The workaround (if you want to call it that) is to use triple colons as the scope resolution operator inside certain cases of variadic macros. The following piece of very contrived code demonstrates the problem. If you look at preproccessed output, its pretty clear that the variadic macro eats colons.
    unix experiments/C++/badmacros> cat badmacros.cpp
    /*************** badmacros.cpp *******************/
    #define INTERFACE(ifc) virtual public ifc
    #define EXTENDS(...) __VA_ARGS__
    namespace foo {
    namespace bar {
       class Interface {};
    }//namespace bar
    }//namespace foo
    #if !defined(HACK_TO_FIX)
       class DerivedInterface : EXTENDS( INTERFACE(::foo::bar::Interface) )
    #else
       class DerivedInterface : EXTENDS( INTERFACE(:::foo:::bar:::Interface) )  
    #endif
    int main(int argc, char* argv[]){}
    /*************** badmacros.cpp *******************/unix experiments/C++/badmacros> CC badmacros.cpp
    "badmacros.cpp", line 18: Error: Identifier expected instead of ":".
    1 Error(s) detected.
    unix experiments/C++/badmacros> CC -DHACK_TO_FIX badmacros.cpp
    unix experiments/C++/badmacros>

    OK - that is good to hear. OTOH, I think I've found another one. The following code builds properly whether or not DEFINE_IN_CLASS_BODY is set on both g++ 3.0.1 and on the online comeau C++ compiler. However, in Forte 6U2, if DEFINE_IN_CLASS_BODY is not set, compilation fails.
    unix experiments/C++/over_template> cat over_template.cpp
    #if defined(DEFINE_IN_CLASS_BODY)
    class Factory {
    public:
       void * create() const {
          return new int;
       template<typename T> T * create() const {
          return reinterpret_cast<T*>(create());
    #else
    class Factory {
    public:
       void * create() const;
       template<typename T> T * create() const;
    inline void * Factory::create() const {
       return new int;
    template<typename T> inline T * Factory::create() const {
       return reinterpret_cast<T*>(create());
    #endif
    int main(int argc, char * argv[]){}unix experiments/C++/over_template> \rm -rf SunWS_cache/; CC over_template.cpp
    "over_template.cpp", line 30: Error: Factory::create() const already had a body defined.
    1 Error(s) detected.
    unix experiments/C++/over_template> \rm -rf SunWS_cache/; CC -DDEFINE_IN_CLASS_BODY over_template.cpp
    This last compile works fine. Using Forte6U2, all the latest patches installed.

  • Forte 6U2 - patch confusion

    While trying to update our compiler to the newest patch set, I ran into the following problem. From access1, patch 111683-14 requires patch 111690-10 or greater to be installed. 111690-10 is not listed on access1 as a patch. When I tried to install 111690-10 after getting it from sunsolve, the patch installation failed, saying that "One or more patch packages included in 111690-10 are not installed on this system."
    111690-10 appears to be an update to the Fortran subcomponent of Forte 6U2, (I guess contained in the Hi-perf package), which we did not install, because we don't use fortran. But this is sort of a problem, because it means that we can't install the latest debugger patch.
    Any suggestions?

    You can find 111690-10 from access1 at:
    http://access1.sun.com/patch.public/cgi-bin/show_list.cgi/wrk/Forte_Fortran_6u2_SPARC
    With the next dbx patch release, the dependency problem will be removed. Please wait until the next dbx patch comes out.
    - Rose

  • Template Template Parameters, Forte 6U2, Forte 7EA

    Forte 6U2 does not support template template parameters. I had hoped to see support added in Forte 7 early access, but they are not supported in that release either.
    While some may argue that template template parameters are the height of C++ esoterica, very sophisticated and usefull libraries like Loki (by Alexandrescu) require them. There are compilers on the market that are capable of handling this construct, and Lippman, who is now at Microsoft, has commited to supporting Loki, Blitz and Boost in future releases of the compiler (see http://www.codeproject.com/interview/stanlippman14nov2001.asp?print=true ). This suggests that microsoft will soon support template template parameters as well.
    I would be interested to see if other people who read this forum care about this issue at all, and if so, please respond so we can try to get Sun to do something about this...

    I absolutely agree that Sun must keep pace with [if not lead] industry and provide the full suite of C++ language features.
    I, too, have spent many hours with Forte C++ 5.3 trying to employ the techniques described in Alexandrescu's "Modern C++ Design" and implemented in his "loki" library. Even recursive template specializations seem not to be supported, though I must do further investigation to confirm.
    And it would be nice if the compiler recognized what I was trying to do and issued a "feature XYZ not yet supported" message.
    ... Dave

  • Local class and switch statement -- compiler bug?

    Does anybody know why the following does not compile with "LocalClass cannot be resolved to a type" error in the case 1: block
    public class ProblemClass {
         public void localClassProblem() {
                   class LocalClass {
                        void doNothing() {};          
                   int i = 0; 
                   switch (i) {                    
                        case 1: {
                             LocalClass instance1 = new LocalClass();  //ERROR: unresolved type
                                            break;
    }while the following does (I only added case 2: where LocalClass type is not referenced within an embedded block)
    public class ProblemClass {
         public void localClassProblem() {
                   class LocalClass {
                        void doNothing() {};          
                   int i = 0; 
                   switch (i) {                    
                        case 1: {
                             LocalClass instance1 = new LocalClass();
                                            break;
                        case 2:
                             LocalClass instance2 = new LocalClass();
    }Is it a compiler bug? Thanks for clarifying this.
    --Michal                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    I'm using 1.5.0-b64
    --Michal                                                                                                                                                                                                                                   

  • Strange compiler bug in method overloading mechanism

    Hi,
    current javac compiler in version 1.4.2_10 and probably earlier versions seem to have a bug in the overloading mechanism of static methods in a certain case.
    I consider reporting this as a compiler bug but would like to have some feedback before.
    Would you consider this class correct? With 5+ years of java experience I'd consider it being correct:
    package test;
    public abstract class AbstractClass {
       public class RealizationClass extends AbstractClass {
          public void someMethod() {
             m(1); //Error: m(int,int) in test.AbstractClass cannot be applied to (int)
             m(1, 2);
       private static int m(int i) {
          return i+1;
       private static int m(int i, int j) {
          return i+j;
    }Interestingly the order of those two static method and their visibility affects the error (changing visibilty to public/protected makes javac accept the code).
    Eclipses compiler does not have this problem, it happily accepts the code above.
    What do you think?
    -Sebastian

    JLS 2.0 says on page 147: "The scope of a declaration of a member m declared in or inherited by a class type C is the entire body of C, including any nested type declarations."
    I read somewhere that in the case a nested or inner class accesses private fields of its enclosing type, the compiler generates "sythetic accessor methods" to allow access. Maybe there's something wrong with the generation of these generated methods...

  • Foreach syntax + generics, Possible compiler bug?

    I'm encountering an odd problem trying to use generics and the foreach (colon) syntax. The code in question:
    for (Iterator<String> it = col.getParameterNames().iterator(); it.hasNext();) {}
    for (String paramName : col.getParameterNames()) {}col is an instance of an inner class of the class whose method this code snippet is from, getParameterNames has the signature:
    public Set<String> getParameterNames();
    The first line, using the Iterator<String> explicitly, compiles fine. The second line, when present, raises the compiler error:
    found : java.lang.Object
    required: java.lang.String
    for (String paramName : col.getParameterNames()) {
    I cannot seem to reliably reproduce this situation in other (simpler) classes I write, but this one in particular seems to trigger it. Is it possible this is a compiler bug, or might there be something I'm doing incorrectly that I'm missing? Are my expectations about how the second line should work incorrect? It seems to in other circumstances...
    javac is 1.6.0_01. Any ideas?

    Here is a quick update, I'm more inclined to think of this as bad behavior now.
    This code compiles:
    public class Test {
    Vector<InnerTest> inners = new Vector<InnerTest>();
        public class InnerTest {        
           public Set<String> someSet() { return (new HashMap<String,String>()).keySet(); }
        public Test() {
            for (InnerTest it : inners) {
                for (String s : it.someSet()) {        
    }however, the following does not:
    public class Test {
    Vector<InnerTest> inners = new Vector<InnerTest>();
        public class InnerTest<P> {        
           public Set<String> someSet() { return (new HashMap<String,String>()).keySet(); }
        public Test() {
            for (InnerTest it : inners) {
                for (String s : it.someSet()) {        
    }Again, the problem might be with my expectations (I haven't gone through the specifications yet with this in mind), but I can't fathom how or why the unused parameter would make a difference in that method's tpye matching.

  • Xerox_mfp scanner not working in arch (compilation bug?)

    I have discovered that my xerox_mfp printer/scanner Xerox Workcentre 3119 is not working in archlinux. However, with the same libsane version, scanner is working in debian.
    I checked the two libraries libsane-xerox_mfp.so.1.0.22: they are different in size.
    I have copied the debian library in /usr/lib/sane and now the scanner is working.
    Compilation bug?
    Last edited by hifi25nl (2011-05-24 17:35:01)

    architecture: x86-64
    samsung scx-4200: xerox_mfp sane backend
    the same problem
    libsane-xerox_mfp.so.1.0.22 from debian libsane_1.0.22-6_amd64 package is working

  • Another Compiler Bug (message: An internal build error has occurred... Unknown Flex Problem)

    I was fighting with this problem for a few days. Finally I've got it resolved. I want to describe it and fill in BUG in the bug report, but I am not sure about Adobe support options. So, I am putting bug report here.
    1. ASSUMPTION: All problems which compiler reports as unknown problem are the real compiler BUGs/Problems. Eventually MXML compiler/ActionScript compiler should be able to take C++ or FORTRAN code or an aribitrary text and nicely tell "Error: It is not ActionScript (Flex) code" or "the code is corrupted from Line so and so...". When compiler crashed, it is most probably due to one of the states not handled (or not handled correct). Keeping this in mind I assume, that my code has nothing to do with the compiler crash.
    2. PROBLEM Description.
         - I tried to port our internal project from Flex3.5/Flex Builder 3 to Flex4.1/Flash Builder 4.
         - After checking out and trying to build code I start getting weird problems like Error 1037: Packages cannot be nested.
         - After cleaning and compiling project by project, walking up dependency tree, I was able to get rid of this problem.
         - On last Project I've got another problem (An internal build error has occurred... Unknown Flex Problem). Which I stuck with for a while.
         - When I checked log file I found following messages:
    ============================================================
    !ENTRY com.adobe.flexbuilder.project 4 43 2010-12-21 15:45:24.353
    !MESSAGE Uncaught exception in compiler
    !STACK 0
    java.lang.ClassCastException: macromedia.asc.parser.InputBuffer cannot be cast to flex2.compiler.as3.CodeFragmentsInputBuffer
    at flex2.compiler.as3.AbstractSyntaxTreeUtil.lineNumberToPosition(AbstractSyntaxTreeUtil.jav a:1266)
    at flex2.compiler.mxml.ImplementationGenerator.generateBinding(ImplementationGenerator.java: 569)
    at flex2.compiler.mxml.ImplementationGenerator.generateBindingsSetupFunction(ImplementationG enerator.java:863)
    at flex2.compiler.mxml.ImplementationGenerator.generateBindingsSetup(ImplementationGenerator .java:812)
    at flex2.compiler.mxml.ImplementationGenerator.generateInitializerSupportDefs(Implementation Generator.java:1878)
    at flex2.compiler.mxml.ImplementationGenerator.generateClassDefinition(ImplementationGenerat or.java:1044)
    at flex2.compiler.mxml.ImplementationGenerator.<init>(ImplementationGenerator.java:206)
    at flex2.compiler.mxml.ImplementationCompiler.generateImplementationAST(ImplementationCompil er.java:499)
    at flex2.compiler.mxml.ImplementationCompiler.parse1(ImplementationCompiler.java:197)
    at flex2.compiler.mxml.MxmlCompiler.parse1(MxmlCompiler.java:168)
    at flex2.compiler.CompilerAPI.parse1(CompilerAPI.java:2871)
    at flex2.compiler.CompilerAPI.parse1(CompilerAPI.java:2824)
    at flex2.compiler.CompilerAPI.batch2(CompilerAPI.java:446)
    at flex2.compiler.CompilerAPI.batch(CompilerAPI.java:1274)
    at flex2.compiler.CompilerAPI.compile(CompilerAPI.java:1496)
    at flex2.tools.oem.Application.compile(Application.java:1188)
    at flex2.tools.oem.Application.recompile(Application.java:1133)
    at flex2.tools.oem.Application.compile(Application.java:819)
    at flex2.tools.flexbuilder.BuilderApplication.compile(BuilderApplication.java:344)
    at com.adobe.flexbuilder.multisdk.compiler.internal.ASApplicationBuilder$MyBuilder.mybuild(A SApplicationBuilder.java:276)
    at com.adobe.flexbuilder.multisdk.compiler.internal.ASApplicationBuilder.build(ASApplication Builder.java:127)
    at com.adobe.flexbuilder.multisdk.compiler.internal.ASBuilder.build(ASBuilder.java:190)
    at com.adobe.flexbuilder.multisdk.compiler.internal.ASItemBuilder.build(ASItemBuilder.java:7 4)
    at com.adobe.flexbuilder.project.compiler.internal.FlexProjectBuilder.buildItem(FlexProjectB uilder.java:480)
    at com.adobe.flexbuilder.project.compiler.internal.FlexProjectBuilder.build(FlexProjectBuild er.java:306)
    at com.adobe.flexbuilder.project.compiler.internal.FlexIncrementalBuilder.build(FlexIncremen talBuilder.java:157)
    at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)
    at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)
    at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:218)
    at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:360)
    at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:516)
    at org.eclipse.core.internal.resources.Project.build(Project.java:94)
    at org.eclipse.ui.actions.BuildAction.invokeOperation(BuildAction.java:221)
    at org.eclipse.ui.actions.WorkspaceAction.execute(WorkspaceAction.java:162)
    at org.eclipse.ui.actions.WorkspaceAction$2.runInWorkspace(WorkspaceAction.java:483)
    at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38 )
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
    !SESSION 2010-12-22 09:48:27.766 -----------------------------------------------
    eclipse.buildId=M20100909-0800
    java.version=1.6.0_16
    java.vendor=Sun Microsystems Inc.
    BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
    Framework arguments:  -product org.eclipse.epp.package.jee.product
    Command-line arguments:  -data C:\Client_Flex4 -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product
    ================================================
    3. RESOLUTION/WORK AROUND
         - I was able to get this problem cleared by putting compiler option for Flex Application projects:  -keep-generated-actionscript
    4. SIDE NOTE
      I do not really see putting this compiler option as the solution and living with the mistery is making me fill a bit bad.

    Hi Faser,
    I just tried it on Vista with our latest FB Plugin build but
    I was unable to reproduce your issue with the following setup:
    - FB Plugin build installed by Administrator account user
    under her Documents folder
    - Administrator account user can launch, create Flex projects
    under her own workspace without any problems
    - Standard account user can launch the FB Plugin build (need
    Admin's password) and create Flex project (default location) under
    his own workspace
    If your setup is different, can you please log a bug at
    http://bugs.adobe.com/flex.
    Be sure to include what build you are using, whether it's
    reproducible, the detail of the setup, etc...
    thanks,
    Sharon

  • SS9 CC5.6 compiler bug - algorithm count confused with struct member

    Found some code that fails to compile in CC 5.6
    CC: Sun C++ 5.6 2004/07/15
    #include <algorithm>
    using namespace std;
    struct A {
      int count;   
    struct B
      struct A *a;
    int main(int argc, char **argv)
      struct B *b = 0;
      // This line fails to build, any other operator is ok
      if ( b->a->count < 50 )
      return (1);
    }Fails with error :
    "c56_algorithm_bug.cpp", line 21: Error: Unexpected ")" -- Check for matching parenthesis.
    "c56_algorithm_bug.cpp", line 22: Error: "," expected instead of "{".
    "c56_algorithm_bug.cpp", line 22: Error: Illegal value for template parameter.
    "c56_algorithm_bug.cpp", line 22: Error: ")" expected instead of "{".
    4 Error(s) detected.The compiler is getting confused with the use of the count struct member vs the count algorithm. Changing the < to a > fixes the problem.
    Using CC5.3 works fine as well as all other compilers we use (gcc 3.4, mipspro 7.4, VC 7.1)
    Anyone seen this ?
    - mark

    This bug has been fixed in the C++ 5.6 compiler. I'm not sure if the fix is in the first patch which is about to be released. If not, the fix definitely will be in the next patch.
    The workaround is not to use
    using namespace std;That using-declaration is a pretty big hammer, and often results in conflicts with user code, compiler bugs aside.

  • Non-constant initializer error; compiler bug?

    The following code snippet demonstrates the issue:
    typedef struct {
    char *p;
    } S1;
    int main()
    char a;
    S1 s = { &a };
    hadron:~/src/misc> cc -V junk.c
    cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
    acomp: Sun WorkShop 6 update 1 C 5.2 2000/09/11
    "junk.c", line 8: non-constant initializer: op "U&"
    The compiler correctly handles the case where 's' is a simple pointer (eg. char *s = &a).  I don't have a copy of K&R handy but surely the C language allows structure initializers to contain address operators.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    Using the code you posted and the following compile line:
    % CC -xO3 -library=stlport4 -g -o stl stl.cpp -V
    CC: Forte Developer 7 C++ 5.4 2002/03/09
    ccfe: Forte Developer 7 C++ 5.4 2002/03/09
    iropt: Forte Developer 7 Compiler Common 7.0 2002/03/09
    cg: Forte Developer 7 Compiler Common 7.0 2002/03/09
    CClink: Forte Developer 7 C++ 5.4 2002/03/09
    CC: Forte Developer 7 C++ 5.4 2002/03/09
    /export/home/SUNWspro/bin/../prod/bin/c++filt: Forte Developer 7 C++ 5.4 2002/03/09
    ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.373
    % dbx stl
    Reading stl
    Reading ld.so.1
    Reading libstlport.so.1
    Reading libCrun.so.1
    Reading libm.so.1
    Reading libw.so.1
    Reading libc.so.1
    Reading libdl.so.1
    Reading libc_psr.so.1
    (dbx) access check
    access checking - ON
    (dbx) run
    Running: stl
    (process id 20274)
    Reading librtc.so
    RTC: Enabling Error Checking...
    RTC: Running program...
    execution completed, exit code is 0
    (dbx)
    Are you compiling with some other option? Does this
    error occur every time or randomly?

  • Forte 6u2 mutex creation problem when debug

    Hi,
    I want to debug my software using forte 6u2 graphical environment but it does not work. When debugging in the graphical env, my software is not able to create some mutex and I can't even step in the code. If I use dbx command line, it works perfectly. Anybody knows what the problem is ?
    Thanks,
    P.S. My software is pretty huge and uses many dynamic lib.

    Can you supply some more details?
    When you say your program can't create a mutex, what does that mean? Do you
    mean that you are calling pthread_mutex_init() and the function is returning
    an error?
    When you say you can't "step" in the code, what does that mean?
    1. you stop somewhere
    2. you hit the "step" button
    3. then what happens?
    a) program continues without stopping at the line you wanted it to?
    b) program doesn't seem to advance anywhere, as if step command was ignored?
    c) program crashes?
    d) debugger crashes?
    Please explain in more detail.
    --chris

Maybe you are looking for

  • This is a valid apple id but not an icloud account

    Please help.. I get this error whenever I attempt to sign in on my Windows 7 PC

  • SQL or Formula in Crystal 8.5?

    Hello Forum Oracles! I am new to Crystal and SQL. I have had no formal training in any aspect of IT but have a good understanding of certain things. I have been around windows based PC since the early 1990s. I need help in writing a formula or SQL I

  • Lost ability to open background windows by sliding cursor to upper right ha

    nd corner and also lost the ability to get to the desktop by dragging cursor to lower left hand corner. It just happened out of nowhere. I love that feature> Can anyone tell me how to turn it back on please? Thanks in advance.

  • Import Bookmarks from HTML

    I am trying to import a Safari bookmarks.html file into Firefox. Your support page says go to "Bookmarks" select "Show All Bookmarks" and select "Import". Please be advised that there is NO "Import" listing under "Show All Bookmarks"! I am using a Ma

  • Oracle suite installation (9i)

    can anyone please tell me why i got this error '9iAS cannot be installed into an existing oracle 9i