Новый стандарт языка C: C18

То есть, когда объект «подыхает» значение указателя на этот объект становится не определно? Не вижу в чём проблема.

Проблема в том, что значение становится другим. Хотя должно было сохраняться последнее записанное.

То есть, ты считаешь правильной такую интерпретацию, что абстрактная машина C подразумевает наличие оракула, следящего за всеми указателями на данный объект и записывающего в них неопределённое значение?

ок. «значение указателя становится неопределенным».

как ты понимаешь это?

По ссылке я не вижу, чтобы гарантировалось, что значение будет другим. Написано «не определено». Таким образом, остальную часть не вижу смысла комментировать.

По ссылке я не вижу, чтобы гарантировалось, что значение будет другим.

То есть, значение указателя и было неопределённым ещё до окончания времени жизни объекта, на который он указывал? :D

Написано «не определено».

Хотя стандарт и определяет «неопределённое значение» как «either an unspecified value or a trap representation», по ответам комитета по стандартизации на некоторые defect reports видно, что «indeterminate value» они понимают как самостоятельное значение. (Например, 8-битный unsigned char имеет 257 значений: 0-255 и indeterminate.)

Таким образом, остальную часть не вижу смысла комментировать.

Это нормально. Про 99.8% шанс не понять в чём противоречие — это относилось и к тебе.

Как это надо по-особому понимать? Написано:

1) Объект (в течение времени его жизни) сохраняет последнее записанное в него значение
2) Значение указателя становится неопределённым, когда заканчивается время жизни объекта, на который он указывает.

Очевидно, что если значение указателя становится неопределённым, то оно уже не сохраняет последнее записанное значение, если мы не считаем, что окончание жизни объекта приводит к записи неопределённого значения во все указатели, указывавшие на него.

Какой глубинный смысл в словах «значение указателя становится неопределенным» можно откопать, который снимет противоречия? Я не понимаю твоего вопроса.

Ну так всё верно, тебе гарантируют что у тебя область памяти будет иметь один статичный адрес по которому можно обратиться к объекту, это так пока ты обращаешься к этому адресу в зоне его видимости тоесть жизни. Ты же понимаешь есть разная память и разное поведение, обычная переменная её значение и адрес указывающий на её значение гарантированно есть в пределах времени жизни процедуры ибо память стековая и если данным не задано именно статичное состояние, тоесть область видимости тут равна времени жизни и наоборот, и по итогу обращение к указателю на данные внутри функции вне функции приводит к неопределённому значению указателя. В противность этому данные в куче имеют иное поведение где область видимости не равняется временем жизни данных. Поведение памяти не определяется одним параграфом. Но конкретно тут тебе сказали «Я те в натуре гарантирую что пока твоя переменная в пределах области своей жинзи указатель на неё будет статичным, но если ты с другого двора обатишься по тому же адресу, извини брат я не гарантирую что по адресу будет жить люся, а не вася»

Это надо понимать как оно в реальной жизни, а не на бумаге вот и всё.

Какой глубинный смысл в словах «значение указателя становится неопределенным

Обычный, верни указатель на локальную переменную в функции и обратись к ней, получишь 0 в значении и NULL по адресу, но в рамках реализации это не гарантируется, тебе может быть возвращён реальный адрес с мусором. Поэтому и не определено, смысл в том что бы дать понять что нечего обращаться к памяти вне её области видимости и жизни ибо реализация допускает как сохранение данных так и нет. И ты можешь получить как типизированное значение и к указателю будет применима адресная арифметика так и нет потому что вне пределов указатель будет просто void *.

тебе гарантируют что у тебя область памяти будет иметь один статичный адрес по которому можно обратиться к объекту

Кстати, что значит «An object has a constant address» нормативно не определено. Сноска — не определение.

Я те в натуре гарантирую что пока твоя переменная в пределах области своей жинзи указатель на неё будет статичным, но если ты с другого двора обатишься по тому же адресу, извини брат я не гарантирую что по адресу будет жить люся, а не вася

Обращаться через указатель с indeterminate value не обязательно. Одно только его чтение приводит к UB. (Но с помощью memcmp в него смотреть можно.)

Кстати, вот тебе кусок кода

    int *p, *q;
    p = malloc (sizeof (int)); assert (p != NULL);
    (free)(p);
    q = malloc (sizeof (int)); assert (q != NULL);
    if (memcmp (&p, &q, sizeof p) == 0)
    {
        // Assume this point is reached     
        *p = 42;  // Line A 
 

Является ли присвоение в Line A определённым поведением?

Не понимаю, к чему ты это пишешь. Ты не согласен с тем, что в том параграфе противоречие или что?

Очевидно, что если значение указателя становится неопределённым, то оно уже не сохраняет последнее записанное значение, если мы не считаем, что окончание жизни объекта приводит к записи неопределённого значения во все указатели, указывавшие на него.

поясни, что значит «запись в указатель неопределенного значения». ты отличаешь по смыслу фразы «значение указателя становится неопределенным» и «запись в указатель неопределенного значения»?

поясни, что значит «запись в указатель неопределенного значения».

То же, что и запись любого другого значения. В чём вопрос?

ты отличаешь по смыслу фразы «значение указателя становится неопределенным» и «запись в указатель неопределенного значения»?

Отличаю. Вторая фраза — это возможный вариант разрешить противоречие. Конечно, выглядит довольно фантастично с точки зрения реализации на обычных машинах. Но как описание формальной модели — норм. Неясно только, как согласовать это с volatile- и atomic-указателями.

Время жизни данных указателя на выделенную память ограничивается от выделения до освобождения. Нет не является определённым. А тут вообще реализация малока втёрлась ибо в освобождённая область памяти для p будет теперь принадлежать q. Можно написать свой алокатор где всё будет по иному, в том и суть. Я вообще gcc расширения юзаю, так что стандарт это так базис, его поведение расширяют все кому не лень. Да и вообще всяких таких финтов лично я избегаю как чупокабры, нахер надо, я лучше буду писать как дебил всё явно лишний раз выделю память и потру чем буду финтить и жанглировать тем в чём неуверен. В Си UB хренова гора, но это не значит что надо использовать то где оно есть.

Ты не согласен с тем, что в том параграфе противоречие или что?

Я считаю что там некорректно/неоднозначно выражены мысли, но если не придираться (но да это надо делать ибо стандарт ) то всё логично.

Утомили вы меня, пойду чай пить с бутером.

Время жизни данных указателя на выделенную память ограничивается от выделения до освобождения. Нет не является определённым.

Не совсем понятно, что такое «время жизни данных», ну да ладно. В общем, твоё мнение совпадает со мнением комитета по данному коду.

Даже если новое выделение памяти вернёт указатель со значением, чьё представление побитово совпадает с представлением значения указателя, который был сунут во free, это не сделает значение старого указателя определённым. Оно останется indeterminate, каким стало после освобождения.

Комитет постановил, что indeterminate-значению (не только указателя) соответствует любое битовое представление. И представление может меняться со временем без прямых действий со стороны программы (имеется в виду запись в объект). Реализация обязана сохранять последнее записанное значение объекта, но не представление этого значения.

Весь вопрос в том, приводит ли окончание жизни к записи в указатели или предложение нужно переделать как-нибудь типа «An object retains its last-stored value throughout its lifetime or the value becomes indeterminate».

Им там надо как у юриков каждое слово/словосочетание звёздочкой пометить где развёрнуто указывать что это такое. ))) Я как выше сказал считаю что надо переформулировать более развёрнуто что бы исключить любое двумыслие/двузначие, тот кто писал там видимо считал, «ну чё и так понятно что я имею в виду». Я бы рад поспорить дальше, но я тупо забываю стандарт , если буду искать дальше какуюто истину то либо из за плохого понимания инглиша сольюсь то ли по иному поводу. Нихачу сливаться поэтому пойду дальше пить чай :) Был бы я профи программером наверное был бы смысл усомнится в чём то или с пеной у рта доказывать иное, но я хз, там много чё написано, но как то привык смотреть как реализовано. Сишка даёт неистовую свободу по UB и выстрелам себе в глаз дёрнув за нитку которая на курке того парня что стоит на крыше и целится на верёвку которая держит многотонную фуру у меня над головой...Поэтому если я и пишу для себя что-то то пишу крайне тупой код где всё явно и просто как у старшеклассника )))))))

«C will never die!C will never die! Перепрошивай.Переперепрошивай.» цитата из песенки Папа любит си.

Вы поймите что ни С ни С++ в ближайшие годы не умрут. Просто по одной простой причине на них написаны 10^9 строчек кода. Многие проекты никогда не будут переписаны на другие языки. Тк это очень сложно и очень дорого.

Многие не любят С. Указывают на его сложность, запутанность и несуразность. Для того чтобы понять почему С такой какой он есть рекомендую прочитать Expert C Programming: Deep C Secrets by Peter van der Linden.

Если коротко то С создавался в те времена когда ещё не было Bourne shell, не было привычного присваивания типа int x=10;операционные системы писались на ассемблере, не было директив типа #define.

И создан он был для нужд программистов, которые писали компиляторы. Потому в нём так много архаичных и не понятных вещей для современного поколения GUIшных манкикодеров.

Достаточно попробовать написать компилятор на хотя бы современном C, и быстро может постигнуть озарение, кто именно занимается «манкикодингом».

Потому в нём так много архаичных и не понятных вещей

Нет, не поэтому. Какую ты вообще тут увидел связь?

Поиск ошибок в C и C++ сейчас очень выгодный бизнес. Не умрут ни компиляторы, ни статические анализаторы, и стандартоклепатели будут пихать свои UB и двусмыслие в стандарт к пущей радости платящих клиентов.

Visual C++ 2017 полность поддерживает С++17.

В C++17 данная программа должна вывести 256. Что выводится в Visual C++ 2017?

#include <iostream>
int main()
{
   int i = 256;
   char c = *reinterpret_cast<char*>(&i);
 
   std::cout << c << '\n';
}

Точнее, такая

#include <iostream>
int main()
{
   int i = 256;
   int j = *reinterpret_cast<char*>(&i);
 
   std::cout << j << '\n';
}

С чего она «должна»? reinterpret_cast, знаковость char, представление целых - это всё IDB.

Стандарт почитай. Всё определено без idb и должно вывести 256

Стандарт почитай

Нет ты