Ага, значит, мы можем переопределить null на конец памяти? Это, кстати, интересная идея и даже более здравая — никто не сможет хранить структуру (объект) в конце памяти. А в начале может.
Тут путаница с самим словом NULL. В том же Паскале используется nil, оно чуть-чуть более нейтрально.
Но, т.к. это представление сильно зависит от платформы, устанавливать значение указателя в особое состояние null необходимо присваиванием нулевого значения целого интегрального типа.
А почему не значения null, которое могло бы быть переопределено? Определено оно для платформы как 0 — будет 0, -1 — будет 0xff....ff?
Из-за проверки if, которая опирается на нулевок значение, а не на null в случае указателя?
Вас не затруднит указать первый стандарт, в котором появилось упоминание этого?
До x86 и AVR были другие архитектуры, зачастую с перекрестными окнами и отдельными внешними аппаратными менеджерами памяти. В которых 0 тоже мог быть корректным адресом.
А Си не требует? malloc из воздуха берется?
Вполне можно взять object pascal диалект, обкромсать его до уровня stub'ов и будет он без рантайма. Например, программа hello world на Delphi укладывается в 1кб, с учетом заголовков PE, выравнивания и т.д.
Секундочку.
Так утверждение стандарта, который говорит «ну, раз в основном у нас по адресу 0 обратится нельзя, то примем это как UB» — это и есть платформозависимость.
О том и речь — если язык портируемый, то какого… зачем, в общем, опираться на особенности реализации какой-то ОС? Если в реализации xyz указатель 0 — некорректный, то это проблемы данной платформы, а не языка. Который портируемый. На разные платформы, ага.
Это кольцевое доказательство, которое ссылается само на себя. Вы запутались.
Разговор идет так: разыменовывание нуля — это UB. Вопрос — почему? Ответ — «раз указатель разыменовывался, он не может быть равен 0». Вопрос — почему? Откуда, мол, такая уверенность, что адрес 0 — невалидный?
И ваш ответ «Потому что если он был 0 и был разыменован, значит мы имеем дело с неопределённым поведением.»
Мне непонятно, почему нулевой адрес считается заведомо некорректным. Нет, точнее понятно — в подавляющем большинстве случаев, реализаций, так и есть. Но это может быть и не так — вполне может оказаться, что в каком-то экзотическом софте адрес 0 доступен.
Допустим, у нас такая ОС и виртуальное адресное пространство так смапировано, что нулевой адрес всегда указывает на валидный участок памяти, и там находится одна из управляющих структур, которых, например, десяток подряд. Адрес 0 — вполне себе валидный, проверять !=NULL нет смысла вообще. Как тогда?
Выше речь шла о командах, т.е. о CLI., поэтому отсыл к git gui не в кассу.
Но инструмент вполне решает свою задачу, хоть интерфейс у него и нелогичен.
Я ничего не говорил о том, хорош ли git, удобен ли, решает ли задачу.
Я даже не утверждал, что у него нелогичный интерфейс для меня лично. Читайте, пожалуйста, внимательнее.
«Нелогичность» команд — вещь не абсолютная. Она может быть относительной для решаемой задачи, что я и пытаюсь объяснить.
Если забивать микроскопом гвозди, его устройство тоже будет нелогичным: зачем здесь поворотные рукоятки? А стекла зачем — это же нелогично их сюда ставить — разбиться могут. А как его держать? За верх? Это нелогично, удобнее же за ручку, которой здесь нет. В общем, нелогичный «интерфейс» (команды), да и сам инструмент.
Тут путаница с самим словом NULL. В том же Паскале используется nil, оно чуть-чуть более нейтрально.
А почему не значения null, которое могло бы быть переопределено? Определено оно для платформы как 0 — будет 0, -1 — будет 0xff....ff?
Из-за проверки if, которая опирается на нулевок значение, а не на null в случае указателя?
До x86 и AVR были другие архитектуры, зачастую с перекрестными окнами и отдельными внешними аппаратными менеджерами памяти. В которых 0 тоже мог быть корректным адресом.
А Си не требует? malloc из воздуха берется?
Вполне можно взять object pascal диалект, обкромсать его до уровня stub'ов и будет он без рантайма. Например, программа hello world на Delphi укладывается в 1кб, с учетом заголовков PE, выравнивания и т.д.
Так утверждение стандарта, который говорит «ну, раз в основном у нас по адресу 0 обратится нельзя, то примем это как UB» — это и есть платформозависимость.
Да. Вы говорите «это UB потому что разыменовывание нулевого указателя некорректно».
Я спрашиваю «почему некорректно» и вы отвечаете «потому что это UB». Ок, я спрошу еще раз — а почему разыменовывание нулевого указателя это UB?
Я как раз о стандарте, о мотивации данного раздела стандарта и спрашивал, если что.
«UB потому что мы разыменовываем нулевой указатель»
Я и спрашиваю — почему разыменовывание нулевого — некорректно.
Писал уже выше, и другие приводили примеры — в других, не мейнстримовых ОС нулевой адрес вполне может быть корректным в виртуальном АП.
О том и речь — если язык портируемый, то какого… зачем, в общем, опираться на особенности реализации какой-то ОС? Если в реализации xyz указатель 0 — некорректный, то это проблемы данной платформы, а не языка. Который портируемый. На разные платформы, ага.
Это кольцевое доказательство, которое ссылается само на себя. Вы запутались.
Разговор идет так: разыменовывание нуля — это UB. Вопрос — почему? Ответ — «раз указатель разыменовывался, он не может быть равен 0». Вопрос — почему? Откуда, мол, такая уверенность, что адрес 0 — невалидный?
И ваш ответ «Потому что если он был 0 и был разыменован, значит мы имеем дело с неопределённым поведением.»
Получилась чушь.
Почему так?
Это почему?
Как насчет операционных систем?
Допустим, у нас такая ОС и виртуальное адресное пространство так смапировано, что нулевой адрес всегда указывает на валидный участок памяти, и там находится одна из управляющих структур, которых, например, десяток подряд. Адрес 0 — вполне себе валидный, проверять !=NULL нет смысла вообще. Как тогда?
Выше речь шла о командах, т.е. о CLI., поэтому отсыл к git gui не в кассу.
Я ничего не говорил о том, хорош ли git, удобен ли, решает ли задачу.
Я даже не утверждал, что у него нелогичный интерфейс для меня лично. Читайте, пожалуйста, внимательнее.
Если забивать микроскопом гвозди, его устройство тоже будет нелогичным: зачем здесь поворотные рукоятки? А стекла зачем — это же нелогично их сюда ставить — разбиться могут. А как его держать? За верх? Это нелогично, удобнее же за ручку, которой здесь нет. В общем, нелогичный «интерфейс» (команды), да и сам инструмент.