Those may still turn up false positives if other files show up that have a legitimate reason to be zero-length, which can happen, particularly in /usr/local where you don't know what third-party software might have been installed. In addition, if you want to scan for other damaged files outside /usr (which you want to do — although the damage usually seems to be in /usr, it's not yet proven that this will always be the case, and the entire file system is full of these HFS+ compressed files), it will turn up a
lot of false positives, since every resource fork file, alias, .webloc file, etc. is going to appear as having a size-0 data fork and extended attributes. What you want to be doing is to specifically test for the com.apple.decmpfs attribute, which will only appear if the file is damaged (for a normal HFS+ compressed file, both com.apple.decmpfs and the resource fork are hidden to the normal interface).
I have written a tool in C to scan for HFS+ damaged files. I'm using it to scan affected people's machines and send the results to Apple, in the hope that they will figure out the issue and fix it. Because this tool is written in C, it will be much faster than the shell, and in addition it will not be dependent on any shell tools which could conceivably be damaged. You can run it with no options to do a scan of the entire hard drive, or send a path as an argument to have it only scan that particular path (but be aware that supplying a path which is not the root to an HFS+ volume will result in a much slower type of search being used). There is also an optional --hidePermissionWarnings flag that you can use to suppress the "Permission Denied" errors and avoid running as root.
Here is the URL.
http://www.charlessoft.com/find_sl_damaged_files.zip
