C sizeof structure member

Something I don’t think I’ve run into with C before.

It can be so hard to come up with a sensible example. So just ignore whether you think I should be doing this. Assume that something similar made sense in context.

typedef struct Foo {
    char uuid[37];
    int value;
} Foo;

char main_foo_uuid[sizeof(Foo.uuid)] = "";
//Compile error!

Doing sizeof(Foo) is fine, but sizeof(Foo.uuid) is not.

One solution is do declare a dummy instance of Foo.

Foo dummy;
char main_foo_uuid[sizeof(dummy.uuid)] = "";
//Works!

But there’s a trick to avoid declaring the dummy: Cast NULL to a pointer to Foo, and use that as your dummy.

char main_foo_uuid[sizeof(((Foo*)NULL)->uuid)] = "";
//Works!

Which makes you wonder why the language couldn’t just support sizeof(Foo.uuid).

strncpy

If you aren’t a C programmer, bail now.

I’ve long wondered why strncpy and strncat were so brain-dead. Recently, I came across the answer. (Which made me go, “Oh...duh!”)

These functions look brain-dead when you try to use them to prevent buffer-overflows. But they weren’t designed to prevent buffer-overflows. They’re simply for copying a substring from the source. Their size parameters are simply meant to be the number of characters to copy from the source, not anything to do with the size of the destination buffer. The expectation, as with strcpy and strcat, is that you’ll figure out if the destination buffer is big enough beforehand.

Look into the strlcpy and strlcat functions from BSD if you haven’t already. They are designed for preventing buffer overflows. It also appears that the similar strcpy_s and strcat_s are on their way into the Standard.

(And now I’m wondering if there should be a strlncpy, that would take both the size of the destination buffer and a count of characters to copy from the source.)

You can also get by with snprintf as a safer replacement for strcpy if adding strlcpy or strcpy_s is not an option. Unfortunately, it can’t stand-in for strcat as easily since passing snprintf the same buffer as the destination and a source is a no-no.

Is Apple prepping a new programming language?

waffle → Surpass:

It is my belief that Apple is definitely working on a new language to surpass Objective-C as their intended, primary, publicly recommended programming language...

I’ve been thinking that it seems very strange that Apple’s primary language is (still) Smalltalk grafted onto C.

If he’s right, I hope that, like the A4 processor (which is ARM based) and Safari (which is HTML, CSS, and Javascript based), it isn’t a wholly new language.

Would Smalltalk be a hard sell to developers who have accepted Objective-C?

Apple’s mistakes

From the iPhone OS 4 SDK, section 3.3.1 of the iPhone Developer Program License Agreement:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This is one of the ways that Apple is keeping Flash off iDevices. It—intentionally—keeps more than Flash off of them. (See “Thoughts on Flash”.)

It is, unfortunately true, that cross-platform frameworks often have lousy user experiences. Not merely “un-Mac-like” but just plain bad. It’s true that they often only end up supporting the lowest common denominator. It doesn’t have to be like that, however. Cross platform frameworks can support platform-specific features. I’ve worked on ones that have. It is all too rare though.

There’s also the fact that some apps—especially some games—don’t really need standard user interface elements. Flash (and other options) can work well for these things. If anyone chooses to use Flash for another sort of app, they’ll quickly lose to non-Flash apps. I’m glad not to have Flash in Safari on my iPhone or my iPad, but I don’t mind Flash apps.

Section 3.3.1, however, doesn’t only ban cross-platform frameworks. It bans writing honest-to-goodness Cocoa Touch apps written in any but the specified languages. (“Platform Control” by Mark Bernstein.)

It has been suggested that a compromise might be to require any frameworks to be open source. (“A reconciling proposal” by Michel Fortin.) That way, any developer that needs access to a specific feature can add it to the framework. That’s a good idea. Yet, the truth is that such extensions to a framework can be a lot of work—especially for someone who normally only uses the framework.

Ian Bogost has written that “Flash is not a Right”. He is right, I suppose.

Putting aside rights, however, I have to wonder if this is really in Apple’s best interest. I have to wonder if this is really in the best interest of Apple’s customers. Apple’s biggest mistakes, I believe, are when they try to compete via the law. Whether through intellectual property or license agreements. They compete and win in the market. They don’t need to play the legal games.

Scheme in the browser (again)

I found myself reading “Popularity” over at Brendan’s Roadmap Updates...again.

This time, a comment by Mike Ivanov stood out to me:

It took almost a decade for ‘average developer’ to grok JavaScript. Now it is understood, at least. How much time would pass before Scheme achieved the same level of acceptance? I bet forever.

Which again has me questioning that. I can’t believe that anyone who has really “grokked” Javascript couldn’t have grokked Scheme. After all, Javascript essentially is Scheme with C syntax. Grokking the language behind that syntax is much more difficult than grokking the syntax.

I think that Javascript was in a unique position. I suspect almost no-one learned Javascript for its own sake. People learned Javascript because it was (essentially) the only game in town for the role it played. (Indeed, it is still too difficult, IMHO, to use Javascript outside that role.)

That’s certainly why I learned it. At the time, I would’ve much rather used Perl, but my customers had Javascript built into their browsers. I wasn’t going to ask them to install client-side Perl.

Likewise, I suspect that Javascript is one of those languages that was the first programming language for a lot of people. Those are people who aren’t coming in with syntax-bias.

Which may be pointless speculation, but that’s what thinking-out-loud is for. I still give thanks to Brendan that I’m required to regularly, at work, program in Scheme/Self even if it is with C syntax.

Objective-C closures

Apple is adding “blocks” (Smalltalk’s name for closures) to Objective-C. See mikeash.com: Friday Q&A 2008-12-26

This is very interesting, but raises a couple of questions in my mind.

Will it require automatic garbage-collection? I believe Apple has also added the option for automatic garbage-collection to Objective-C as well.

The bigger question, though, is after adding Smalltalkesque objects and message-passing, automatic garbage-collection, and Smalltalkesque closures to C, why aren’t you just using Smalltalk instead?

Tips for interviewing for a C programming job...

Don’t come to an interview for a C programming job if you can’t do simple type analysis. Just stay home. If I ask, “Given void *p, what are the types of the expressions p, *p, and &p?”, you should know the answers. Furthermore, you should know that—in that context—return *p is a compiler error and why. You should not be confused or scared by char **x. You should understand why printf("%p\n%p\n", ((char *) p) + 1, ((char **) p) + 1) prints two different numbers.

The Next Big Language

Steve Yegge blogged about The Next Big Language. (Yeah, yeah. I’m behind on my Google Reader reading and on finishing draft blog posts.) I wonder if anyone has ever grafted C-ish syntax onto Common Lisp—along with some prettifying of it’s libraries. Kind of like Dylan, but with syntax closer to C than to ALGOL. I’m not sure it’s a great idea, but it seems like such a thing would attract some attention.