So I found this little security clanger in the manual page for dlopen on Mac OS X, where it states:
When path does not contain a slash character (i.e. it is just a leaf name), dlopen() searches the following until it finds a compatible Mach-O file: $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH.
Yes, current working directory, one of the classic vulnerability injection mechanisms. This is as epically bad a security clanger as Microsoft Windows’s LoadLibrary call but, apparently, nobody cares! Linux, and Solaris have a far more sensible mechanism, where it actually enumerates the places that it looks for the library, but unless you really, horrendously eff it up, it won’t look in the current working directory.
I nearly did a spit-take when I saw this explicitly called out. In this day and age, it’s an embarassment.
Nothing more than a rant….
It’s not that tough – when using most english locales, we sort case insensitively. a==A, B==B and so on. Pragmatically, the only reason for picking a locale other than UTF-8.generic is because I would really, really like these rules obeyed.
I am sick to death of having to work around stupidity.
I’m just complaining as I look at the output from ls and it’s pretty much a case sensitive sort. I’m sure that accents are sorted correctly in EN_ie – after all á is the same as a, but apparently it’s different to A.
Sorting it difficult… the rules are so complicated… stop complaining! you’re able to perform at least 600 million operations per second, and a table lookup for a case insensitive sort is probably going to cost 20.
Bear in mind that the number above was a quick back of the envelope number of an iPhone. I’m sure a real computer will be able to do something a little better…
Looks like it’s not Linux, it’s only Leopard that doesn’t understand EN_ie collation. Oh well, that’s life I suppose…
Apparently I forgot to plug out my null before quitting the application. That’s a shame as I thought I had two or three nulls floating around
the use of the
signal(int signum, void (*handler)(int))
is a smidgin dangerous on various operating systems. Under Solaris, for example once the signal has been delivered to the process the signal handler is reset, so a typical piece of code that wants to reuse the signal handler repeatedly will typically set the signal handler again when receiving the signal. This leads to a minor race condition where upon receipt of the signal and the re-setting of the handler the process receives another copy of the same signal. Some of these signals cause Bad things to happen – such as the stopping of the process (SIGTSTP for example). Under Linux it keeps the signal handler in place, so you have no fear of the event triggering an unwanted event.
The manual page for
under Linux makes it clear that the call is deprecated in favour of the much more functional
sigaction(int sig, const struct sigaction *restrict act, struct sigaction *restrict oact)
call, which keeps signal handlers in place when you don’t pass the SA_RESETHAND parameter as part of the sa_flags parameter of the sigaction structure. So you get to explicitly choose to accept a signal once, and then have the system deal with it in the default manner afterwards.
Signals, are of course a real pain in the ass when dealing with sub-processes. For example the use of ptrace to perform profiling works well until you fork. If another SIGPROF signal arrives before you can create your signal handler then the child process is terminated as that’s the default behaviour in that situation.
Under Solaris (and Leopard) you can make use of dtrace to perform profiling on a set of processes without needing to deal with vagaries of signal handling, making this a non-issue. For those of you stuck in LD_PRELOAD land, probably the only thing that can be done is to set the signal disposition to be ignored before execing the new process. you have a small window where the profiling is missing, but the overall increased stability of the application is improved by preventing it from accidentally being terminated due to a profiling signal being received too soon. I know the accuracy nuts would hate that, but it’s part of the price of dealing with standards.
apparently it could have something to do with the theme, but this morning I noticed that the GrowlHelperApp was using about 200MB of wired down memory.
Restarting it seems to have restored it to a reasonable size, but I shall set up a dtrace script to keep an eye on it.
It’s a bit funny to mention this, but the mobileme calendar badge has the correct date. Just like the calendar date on the macosx desktop and the iphone/touch (which took a while to get right.
Yes, I know; completely trivial
I don’t want to keep manually syncing my address book on Vodafone with that of my mac, so I use this script to pull out the phone numbers of people when I want to send them a text message using webtext (or my webtext script).
args=$(getopt s:r: $*)
set — $args
while :; do
case $1 in
-s) search_for=$2; shift;;
-r) return_val=$2; shift;;
—) shift; break;;
if [ $# -lt 1 ]; then
echo 1>&2 "usage: $(basename $0) -s <search> -r <return> YOUR_SEARCH"
for i in $@; do
if [[ -z $search ]]; then
search="($search_for contains \"$i\")"
search="$search and ($search_for contains \"$i\")"
scriptcode="tell app \"Address Book\" to get (value of $return_val) of every person where $search"
osascript -s "s" -e "$scriptcode"
You can get it Here.
It looks like we have a bunch more sync options for the address book now. I don’t believe it supported Exchange or Google prior to 10.5.4, now it does. Let the insanity of address book syncing continue.
It’s kind of noticeable. Respect the grid!
I wonder what it looks like on windows…
I would not recommend using spaces on a multi-monitor setup. It’s just a bit too painful to use. Things just disappear into the pit of another space.
It works well on a single-monitor setup though.