¿Es necesario verificar NULL después de asignar memoria, cuando el kernel usa memoria de sobrecompromiso?

Es una práctica general verificar NULL (si la memoria se asignó correctamente) después de un malloc (), algo así como

void *ptr = malloc(10);    
if (ptr != NULL) {  
  // do some thing usefull  
} else {  
 // no memory. safely return/throw ...  
}  

con el exceso de memoria habilitado en el núcleo, ¿hay alguna posibilidad de obtener NULL? ¿Debo seguir la práctica de verificar religiosamente NULL para cada asignación? ¿Malloc devolverá NULL a pesar del agresivo mecanismo de sobrecompromiso (supongo que el valor 1)?

De hecho, el kernel de Android utiliza un exceso de compromiso de memoria (no estoy seguro sobre el valor, me encantaría saberlo (valor de exceso de compromiso) y su importancia). Parte del código fuente del marco (C / C ++) en Android (puede ser de terceros) no verifica NULL ni captura bad_alloc después de las asignaciones. ¿Me estoy perdiendo de algo?

Hay algunos subprocesos en SO con respecto a la memoria de sobrecompromiso, pero ninguno de ellos resolvió mi confusión.

EDITAR: Si se está empleando un compromiso excesivo agresivo, no se devolverá NULL (supuesto 1). Cuando no hay memoria física disponible y al intentar acceder a la memoria asignada (escribir en la memoria asignada), OOM eliminará algún proceso y asignará memoria para la aplicación hasta que se elimine por turno (supuesto 2). En cualquier caso, no veo ninguna necesidad de chequear NULL (memoria asignada o proceso eliminado). ¿Estoy en lo cierto en mis suposiciones?
La portabilidad no es una preocupación para esta pregunta.

Respuestas a la pregunta(5)

Su respuesta a la pregunta