Вообще-то, это обычная логика. По-твоему, логично, что сущность с названием null pointer может быть не равна нулю? Почему-то null pointer constant всегда равна нулю, а null pointer - нет. Логично то, что можно получить не ноль, присвоив чему-то ноль в языке без перегрузки операторов? Логично то, что сравнение ненулевого значения с нулём возвращает true? Все смеются над JavaScript с его неявными преобразованиями, но кода это касаеться C - "это другое". Это не моя логика "неправильная", а в C логика не работает, потому что комитет стандартизации решил использовать ноль для обозначения невалидного указателя, а потом оказалось, что где-то нулевой адрес вполне легитимен, и теперь мы имеем терминологию, имеющую лишь косвенное отношение к реальности, и поведение компилятора, которое в народе называется ugly hacks. Но, конечно, это моя вина, что я не прочитал ВЕСЬ стандарт, а там наверняка где-то написано, что null pointer - это не всегда null. Ну и, конечно, всё-таки, лучше использовать специальную константу NULL и не выпендриваться, учитывая количество подводных камней в C.

Что касается Rust, там в 99.9% случаев вообще нет необходимости в сырых указателях, и код, аналогичный по смыслу clearenv(), будет написан совершенно иначе, примерно так:

use std::sync::Mutex;

pub enum ClearEnvError {
    MutexLock
}

pub fn clear_env() -> Result<(), ClearEnvError> {
    extern {
        static ENVIRON: Mutex<Vec<String>>;
    }

    unsafe { ENVIRON.lock() }
        .map(|mut environ| environ.clear())
        .map_err(|_| ClearEnvError::MutexLock)
}

Здесь есть и обработка ошибок и примитив синхронизации, необходимый для вызова функции из других потоков. Самое прекрасное - компилятор практически заставит всё это сделать, и чтобы накосячить, придётся дополнительно постараться.

Но если всё же понадобится иметь дело с сырыми указателями, то я просто прочитаю соответствующие главы документации и Rustonomicon, прежде, чем приступать к делу. И, конечно, споткнувшись в этой ветке на приколы с сишным понятием null pointer, на этот раз я буду читать доки внимательнее, хоть они и намного понятнее, чем стандарт C.