Vincent Gable’s Blog

December 25, 2009

A C &Puzzler[]

Filed under: Announcement,Bug Bite,C++,Objective-C,Programming | , , ,
― Vincent Gable on December 25, 2009

Here’s a C-puzzler for you!

given this function,

void foo(char* s){
	printf("s is at: %p\n s is: '%s'\n", s, s);
}

and that

char s[] = "Joy!";
foo(s);

prints out

s is at: 0xbffff46b
s is: ‘Joy!’

what will this next line print?

foo(&s); //WHAT WILL THIS DO?

Pick all that apply:

  1. Print “Joy!”
  2. Print garbage
  3. Print the same address for s
  4. Print the a different address for s
  5. Crash
  6. Go into an Infinite loop

Answer

Answer: one and three

Yeah, it’s not what I expected either, especially since:

@encode(__typeof__(s)) = [5c]
@encode(__typeof__(&s)) = ^[5c]

In fact, all of these are equvalent (modulo type warnings):

foo(s);
foo(&s[0]);
foo(&(*s));
foo(&s);

Explanation.

December 9, 2009

Compile Safer

Filed under: Bug Bite,C++,Cocoa,iPhone,MacOSX,Objective-C,Programming | , , ,
― Vincent Gable on December 9, 2009

Peter Hosey explains what warnings he uses and why. It’s good, but long. Fortunately, you can just grab a script, and enable those warnings in your Xcode projects.

Warnings = Errors

If I could force just one compiler flag on everyone who’s code I use, it would be TREAT_WARNINGS_AS_ERRORS. As a rule, things don’t get improved if they aren’t broken. (How many times have you said “I’ll come back and fix this code later”? Yeah.) Warnings fester and grow on each other, until they cause a real breakage. It’s an inescapable evil of building software with finite resources.

If a warning isn’t worth stopping the build over — it’s not worth checking for in the first place.

Use the Latest Tools

Specifically, if you aren’t using Snow Leopard and Xcode 3.2 to build your Objective-C code, you are crazy. Trust me, painless static analysis is worth upgrading for. It catches maddening memory leaks, not just trivial type errors, like adding an int to an NSArray, that you would catch immediately.

June 15, 2009

Ignoring Just One Deprecated Warning

Filed under: Bug Bite,C++,iPhone,Objective-C,Programming,Tips | , , , , ,
― Vincent Gable on June 15, 2009

Switching projects over to iPhone OS 3.0 means discovering that functions I’m using are deprecated. Occasionally there isn’t a totally straightforward replacement, and the best thing to do is to file a bug/TODO/note for myself, and ignore the warning until a later version, when major refactoring will be possible. But bitter experience has taught me to have Xcode treat warnings as errors1, so it’s necessary to trick the compiler into ignoring the warning for things to build.

-Wno-deprecated

The -Wno-deprecated flag tells GCC to suppress warnings about deprecated code. But adding it to an Xcode project means you won’t get useful warnings about other depreciated code.

You could file a bug telling yourself to turn that warning back on after the deprecated functionality has been updated. That should work just fine. But it feels like bad project hygiene to me.

Casting and Protocols

Type casting is a dangerous old-C technique that’s earned its infamy. But it’s undeniably fitting to use a deprecated language feature to get deprecated code to build. The basic idea is to declare a protocol that includes the method you want to suppress warnings for,

@protocol DeprecatedHack
- (void) myDeprecatedMethod;
@end

then just cast your objects so the compiler thinks they implement the protocol,

[foo myDeprecatedMethod]; //warnings
[(id<DeprecatedHack>>)foo myDeprecatedMethod]; //no warnings

Although having to declare a protocol is somewhat heavyweight, it leaves a nice artifact in the code reminding you to replace deprecated functionality.

Protocols Not Required

Sometimes just casting to id is enough. This happens if another object has a non-deprecated method with the same name.

1For experimental or prototyping projects I let warnings slide. But in the main project I always treat warnings as errors. Ignoring them in production code has never worked — warnings fester and grow on each other.

Because Objective-C is so dynamic, there are many errors that the compiler can warn you about, but can’t be totally sure are errors. For example, methods can be added to a class at runtime, so if you call -someMethodThatDoesNotExistAnywhere, the compiler will warn you that something is up, but won’t stop the build, because the necessary code could magically appear at runtime. Of course, 99% of the time, it’s me accidentally using count when I meant length, etc. What I’m really trying to say here is that treating warnings as errors is an even better idea in Objective-C.

November 24, 2008

How To Put a % in an NSString/NSLog/printf

Filed under: Cocoa,MacOSX,Objective-C,Programming | , , , , , ,
― Vincent Gable on November 24, 2008

%% is turned into a single % in a call to NSLog, or -[NSString stringWithFormat:], or the printf-family of functions.

Note that %%format will become %format, even if %format usually prints an argument. For example, the code

NSLog(@"%%a will print a float in a machine-readable format, so that *scanf can read it back in from a string with no loss of precision.", 1.0f);

prints:

%a will print a float in a machine-readable format, so that *scanf can read
it back in from a string with no loss of precision.

not:

%0x1p+0 will print a float in a machine-readable format, so that *scanf can read it back in from a string with no loss of precision.

July 5, 2008

-dealloc Warning

Filed under: Bug Bite,Cocoa,MacOSX,Objective-C,Programming |
― Vincent Gable on July 5, 2008

The only time you should call ever call -dealloc in Objective-C is on the last line of your own -dealloc method. This call should be [super dealloc];. The proper way to dispose of an object is to send it a -release message — -dealloc will then be called if appropriate.

Now when I was first learning Cocoa, I sometimes disposed of objects by calling -dealloc directly. This caused all sorts of problems. Truth be known, if I’ve been messing with several object’s -dealloc methods, I’ll sometimes dyslex out and type dealloc when I mean release, just because it’s more fresh in my head. This is very rare, but it has happened once, and will happen again. I’m fallible like that. Murphy’s law tells us that I won’t catch it every time.

So I humbly propose that GCC should warn you if you use -dealloc any way other then calling [super dealloc]; on the last line of your own -dealloc methods.

Powered by WordPress