views:

293

answers:

4

This is really several questions, but anyway...

I'm working with a big project in XCode, relatively recently ported from MetroWorks (Yes, really) and there's a bunch of warnings that I want to get rid of. Every so often an IMPORTANT warning comes up, but I never look at them because there's too many garbage ones. So, if I can either figure out how to get XCode to stop giving the warning, or actually fix the problem, that would be great. Here are the warnings:

  • It claims that <map.h> is antiquated. However, when I replace it with <map> my files don't compile. Evidently, there's something in map.h that isn't in map...
  • this decimal constant is unsigned only in ISO C90
    This is a large number being compared to an unsigned long. I have even cast it, with no effect.
  • enumeral mismatch in conditional expression: <anonymous enum> vs <anonymous enum>
    This appears to be from a ?: operator. Possibly that the then and else branches don't evaluate to the same type? Except that in at least one case, it's (matchVp == NULL ? noErr : dupFNErr)

    And since those are both of type OSErr, which is mac defined... I'm not sure what's up. It also seems to come up when I have other pairs of mac constants...

  • multi-character character constant

    This one is obvious. The problem is that I actually NEED multi-character constants...

  • -fwritable-strings not compatible with literal CF/NSString

    I unchecked the "Strings are Read-Only" box in both the project and target settings... and it seems to have had no effect...

+1  A: 

That decimal constant is written like 3111222333UL?

ndim
Even better: UINT32_C(3111222333)
nall
@nall: Thanks for mentioning that. I was not aware of it, but it makes a lot of sense. Will use it from now on.
ndim
+3  A: 

Items in <map.h> are in the global namespace while items in <map> are in the std namespace. Most likely you were just referring directly to the global versions and when you switched to <map> you were no longer seeing them because they moved to std::. In source files add a using namespace std to move on quickly. In headers you'll need to qualify uses of map-related items with std::.

I think you'll need to qualify the literal constant value with a trailing UL so it knows the correct type of the literal.

Most likely the enums are in two separate OS defined anonymous enums. You can static_cast them to quiet the warning.

No idea on the multi-byte chars.

Can you disable -fwritable-strings? Can you refactor the code that needs to modify constant strings?

Mark B
I need the writable strings mainly because the alternative is to go through and make a whole lot of char * into const char*... I'll get around to that one of these days...
Brian Postow
+2  A: 

"multi-character character constant"
This one is obvious. The problem is that I actually NEED multi-character constants...

Compile with -Wno-multichar -- add it to Other Warning Flags, and leave the Four Character Literals warning switched off.

Of course, whether this legacy code's multi-character character constants actually mean the same thing as they did under Metrowerks probably on a different architecture... is an open question.

John Marshall
Multi-character constants for MacOS (pre-MacOSX) compilers tended to just stick the characters into an array, so `'dht1'` would be similar to `char foo[4] = {'d','h','t','1'};`, so they'd be useful for MacOS file metadata. I don't offhand know how the gcc in XCode handles multichar constants, but the MacOSX file structure is straight Unix, and doesn't use the four-character file and application IDs.
David Thornley
@David: Uh, no. Those compilers interpreted them as integers of the "appropriate" size in the "obvious" way, leaving you open to endianness excitement. On a sensible big-endian host, the layout in memory would be the same as your array; in the modern all-the-world's-Intel regime, not so much. // Your point about modern MacOSX not using multi-character character constants so much if at all is right, but the OP doesn't say what he's using them for...
John Marshall
@John Marshall: The endianness excitement didn't really happen, as MacOS was dead by the time Apple moved to Intel, and the 68000 and PPC were both (unless I'm remembering way wrong) big-endian. It was pretty much necessary for all Mac compilers to do the same thing, obvious or not. I don't know what the OP was using them for, but file metadata was by far the biggest use back then.
David Thornley
@David: The point is that __this OP__ is about to encounter the excitement if he just disables this warning without looking at what all these multi-character character constants are doing in his code!
John Marshall
I'm not sure why, but I don't seem to be experiencing endian issues. Possibly because I'm flipping them twice... I'm just comparing the 4 char code to the code of the resource in the rsrc file... if both are backwards, then no big deal...
Brian Postow
A: 

I discovered that at least as of Xcode 3.2.4 you can make the warning go away by using a number of characters in the constant that is the correct length for the type.

For example I had a constant that was only 3 chars long 'TT2' and it was giving me the multi-character character constant error. Adding 0's to the constant made the errors go away, like so: '\0TT2'.

Jon Steinmetz