• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: dlopen woes under XCode 2.1
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dlopen woes under XCode 2.1


  • Subject: Re: dlopen woes under XCode 2.1
  • From: Quinn Dunki <email@hidden>
  • Date: Sat, 25 Jun 2005 22:42:52 -0700

Thanks for all the replies on this one. The most common suggestion I received was to add braces around my cases. The code has them actually, I just erased them by mistake when I reformatted the code for email.

One reply suggested adding breaks after the returns in each case. This doesn't seem like it would do much, but I tried it just in case the compiler would be happier with them for some reason. It didn't help, unfortunately. The same illegal code is still generated. I also tried replacing the returns with breaks, although the rest of the code not shown in the email requires them to be returns. Isolating the problem in a test app didn't help either- the problem goes away when I do that. It must be something about the target or my configuration.

Just to clarify, the illegal instruction occurs when it attempts to branch to the correct case for foo. It never actually gets there, so it doesn't touch the goo line, or the return. Instead of branching, the bgt- instruction falls through to the next line of assembly which is junk (a badly formatted lwa, to be precise).

Sandy


On Jun 25, 2005, at 4:39 PM, Lawrence Gold wrote:

Quinn Dunki wrote:

Upon further investigation, I've learned more about this problem. It
appears to be only 1 of my 8 plugins that is malfunctioning.
Furthermore, it is doing so in a very specific way. For some reason,
when it encounters this block of code (simplified for testing):

            switch (foo)    // foo is 0-3
            {
                case 0:
                case 1:
                case 3:
                    int goo=0;
                    return;

                default:
                    int bar=1;
                    return;
            }


It shouldn't make a difference, but could you enclose the bodies of the
case statements in { }? For example,


    case 0:
    case 1:
    case 3:
        {
            int goo=0;
        }
        break;

GCC should warn about the code you gave in the example, though I think
it shouldn't be a problem for built-in simple types like 'int'.



_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Xcode Project File Format (From: Michael Rice <email@hidden>)
 >Re: Xcode Project File Format (From: Mike Lazear <email@hidden>)
 >Re: Xcode Project File Format (From: "Corey O'Connor" <email@hidden>)
 >Re: Xcode Project File Format (From: Scott Tooker <email@hidden>)
 >Re: Xcode Project File Format (From: Michael Rice <email@hidden>)
 >dlopen woes under XCode 2.1 (From: Quinn Dunki <email@hidden>)
 >Re: dlopen woes under XCode 2.1 (From: Quinn Dunki <email@hidden>)

  • Prev by Date: Re: How to make XCode use a shared build location inside an application package?
  • Next by Date: Re: Using XCode and en.lproj vs. English.lproj
  • Previous by thread: Re: dlopen woes under XCode 2.1
  • Next by thread: Non-Apple compiler integration in Xcode 2.1
  • Index(es):
    • Date
    • Thread