Spot the error:
uuid_t uuid_now;
uuid_generate(uuid_now);
char *uuid_cstr;
uuid_unparse_lower(uuid_now,uuid_cstr);
The error is that uuid_cstr is not initialized. I was writing the original code up to uuid_unparse_lower by hand but then I got lazy and googled, and found that yeah, it was done that way. What I missed was that in every instance this was shown, they were using char uuid_cstr[37] and were thus actually initializing their string^Wchar array — 36 chars + the null — while I was just declaring a pointer.
This all boils down to that packing up services worked great in ThisService, provided you were lucky and the program ran in pre-zeroed space, or the application wouldn’t, when this was turned into a string seconds later, find the null string terminator and crash and burn horribly.
Whoops.
I fixed this (by also forgoing it for CFUUID) and, humble from experience and eager to shoot down anything else pre-emptively, ran and reran the wonderful clang static analysis program — earlier in the week that just ended, I proposed the name “clunk” but am now coming around to “mechanical Hosey” as well — on the source code for about an hour until most kinks were worked out. Then I updated some web pages in which process is still as embarrassingly manual as is the “memory management” in most Objective-C applications (unless you write only 10.5 applications), and I uploaded a new version and slapped “2.0.2″ to the side of it.
Moreover, I advise that the iPhone software platform must be opened.
Actually, it’s not a matter of being “initialized” or not… it’s whether or not the name uuid_cstr points to any allocated memory or not, whether that memory is on the stack (like with char uuid_cstr[37]) or on the heap (if you use malloc or something like that).
At least in C (perhaps this is different in Objective-C?) declaring a local array “char uuid_cstr[37]” will *not* in fact initialize it to anything in particular, but uuid_unparse_lower should add the trailing NUL. The issue isn’t whether or not the data pointed to by uuid_cstr is initialized; it’s whether or not you control the 37 bytes pointed to by it, so that it’s safe to write to without possibly corrupting random parts of memory or otherwise screwing things up.
By David Glasser · 2008.10.27 18:18
Yes it is.
And if
uuid_cstrisn’t initialized, then it may point to allocated memory, or not. If it doesn’t (as in the case of at least one user), the program crashes.If
uuid_cstris initialized to some valid memory, then it will not cause the program to crash.Of course not, since
uuid_unparse_lowerwill overwrite it anyway. The problem is whether theuuid_cstrpointer itself is initialized. It wasn’t, which was why the program would crash.By Peter Hosey · 2008.10.29 01:32