I pointed out two issues with breaking the locks.

Your response addressed the less important issue:

- the guarantee that log records don't interleave is lost

Since the documentation seems to be silent the guarantee (or expectation) is implied - logging systems emit records atomically - if this isn't true across fork() then the exception should be documented.

but it didn't address the more fundamental problem:

- when the child enters the code 'b' is undefined

i.e., breaking the lock will allow the child to access data in an undefined state.  This will result in either core dumps or hangs (presumably the motivation for the original change was to prevent this?).

For instance, if the fork() happens while a thread is holding the <stdio.h> FILE lock on a log file, then the child trying to access that FILE will hang.