Mistake on hook_help implementation causes fatal errors

This messes up other help modules. It's tiny, but it breaks other help pages so I'm moving this up to critical.

Which module calls this function with NULL as a second parameter?

From the hook_help() documentation:

$arg:
An array that corresponds to the return value of the arg() function, for
modules that want to provide help that is specific to certain values
of wildcards in $path. For example, you could provide help for the path
'user/1' by looking for the path 'user/%' and $arg[1] == '1'. This given
array should always be used rather than directly invoking arg(), because
your hook implementation may be called for other purposes besides building
the current page's help. Note that depending on which module is invoking
hook_help, $arg may contain only empty strings. Regardless, $arg[0] to
$arg[11] will always be set.

So I'm pretty sure that the caller is in the wrong here, not this module. I'm just taking the coding standards more seriously than others (including parts of core).

Rubik theme is one of the culprits, I submitted an issue and a patch: http://drupal.org/node/1996474

I just encountered this bug. Yes, it's now fixed in rubik #1996474: module_invoke for hook help is generating a fatal error for some modules (not in the full release), but for anyone who isn't using that beta release that came out a week ago (which is most people) will still encounter this avoidable fatal error. The official API documentation which you linked to reads:

function hook_help($path, $arg) {

You're not wrong about $arg containing arrays, but some points aren't worth making. Your implementation deviates from the official API and it's causing avoidable problems.

Please reconsider.

Now it makes less sense than ever. It is actually fixed in Rubik and there's a new release, so either people can just update Rubik – or we can commit this workaround, people can wait for our next release and then update this module instead of Rubik. Why would this have any advantage?
I agree my position is disputable, but I just think it's important to adhere to the coding standards, and I don't like to compromise there just because of errors in other modules. (That's also why I hate working with Views.)

For fixing fatal errors, especially since it apparently took over a year to solve them otherwise, it might have been the better option (even though it would have meant that the Rubik error probably wouldn't have been fixed at all), but it doesn't really make any sense anymore, as explained above.

Upgrade of Rubik helped. Thanks.