Произошло очередное заседание комитета C++

Ну это потому что ты туда заведомо null передаёшь, и они это могут отследить.

Но на деле доступа тут не осуществляется и разыменования nullptr тут нет. Только подсчёт адреса.

По факту это эквивалент

struct usb_line6 *line6 = podhd + offsetof(struct usb_line6_podhd, line6);

И вся проблема в том, что компиляторы (как минимум кланг) воспринимают за ub адресные операции с nullptr, а не сам факт обращения к данным по адресу. https://gcc.godbolt.org/z/a4bPc1s6b

Ребята из PVS-Studio написали на эту тему статью: https://pvs-studio.com/en/blog/posts/cpp/0306/ Там же есть и ссылки на дополнительные материалы.

Тогда можно переформулировать и сказать, что это проблема не компилятора, а стандарта, т.к. считать вычисление адреса неопределённым поведением, как минимум странно. Доступ по адресу может быть неопределённым поведением, а сохранение адреса в переменную не должно быть таковым.

Я могу заблуждаться, но ведь не обязательно nullptr должен физически представляться значением 0. Это к 0 мы можем добавить некое смещение и получить осмысленное значение. А вот если nullptr – это, условно (uintptr_t)-42, то добавление к такому значению чего-либо не дает осмысленного результата. Поэтому и вычисление такого адреса не имеет смысла, как и сохранение результата подобного вычисления.

Кроме того, мне не понятен смысл этого разговора. Вот есть стандарт, международный, выдержавший несколько обновлений. В нем зафиксировано вот так.

Зачем эти стенания на LOR-е?

Если есть желание изменить стандарт, то https://stdcpp.ru/ и вперед.

Если нет желания, то пока что здесь вот так. И это вот так лучше учитывать, чтобы в один прекрасный момент программа не перестала работать будучи скомпилированной новой версией компилятора (или компилятором от другого производителя). Причем поведение компилятора будет полностью соответствовать стандарту.

реально говнокод. Получать указатель на line6 в том месте ненужно.

И кто же победил? Линус или gcc?

не обязательно nullptr должен физически представляться значением 0

Там скорей всего не в этом была проблема - а в агрессивных оптимизациях, которые лезут в поля.

https://github.com/torvalds/linux/commit/8a3b7c086a509d90c312ebab6d8e5a9bf48c6cf5

https://github.com/torvalds/linux/commit/188e664502dc47f83775a556e6db52cd8cc0b5fc

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

Потому что такова жизнь. Есть теория, есть практика. Точно так же как рок-звёзды ничего не стоят без толпы своих поклонников, так и разработчики компиляторов / члены WG21 нафиг никому были бы не нужны без миллиардов строк кем то уже написанного (и даже иногда работающего, спешу заметить) кода. Не надо недооценивать voting power потребителей.

ведь не обязательно nullptr должен физически представляться значением 0. Это к 0 мы можем добавить некое смещение и получить осмысленное значение.

Это значение не обязано быть осмысленным. Почему вообще на байтики в памяти накладывается требование осмысленности, если они не используются?

Зачем эти стенания на LOR-е?

Зачем вообще лор без стенаний на нём?

И это вот так лучше учитывать

Ну вот я лично по результатам этого треда преисполнился пониманием, что именно надо учитывать, за что тебе и fsb4000 отдельное спасибо.

Менее странным стандарт от этого не становится, впрочем менять я его, конечно же, не буду.

А по каким критериям принимают в данный комитет?

А по каким критериям принимают в данный комитет?

Ты будешь приходить на встречи комитета, хотя бы на одну встречу очно 😸

https://imgur.com/a/ojgW4D4

Очень интересно. А на одну встречу — это в течение какого промежутка времени? И регламентировано ли количество членов комитета?

А на одну встречу — это в течение какого промежутка времени?

Дней 5.

Следующая встреча:

2022-11-07 to 12: Kona, HI, USA: Standard C++ Foundation

И регламентировано ли количество членов комитета?

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

Вот тут можно посмотреть список людей на февральской встрече, в 9. Attendance

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/n4907.pdf

(кстати, напротив Antony Polukhin не стоит Yandex, странно)

Ну и так основные барьеры вступления в комитет это то, что за это не платят, а расходы на посещение нужно нести. 3-4 встречи в год.

Понятно что крупные компании могут оплатить перелёт и гостиницу, но если ты хочешь сам и это для тебя как хобби, то это дорогое хобби.

Например, PHD (из этой темы #embed принят в C23), если я правильно помню, собирал деньги на patreon на расходы для посещения встреч комитета.

После начала пандемии, так как очно встречаться было нельзя, то стали встречаться в Zoom. Встречаться в Zoom гораздо дешевле чем лично, но, конечно не так продуктивно. Фактически из неудобств, это то что встречи обычно начинаются в 8:00AM pacific, что может быть неудобно в зависимости от часового пояса.

Сейчас, когда ограничения по пандемии сняты и обсуждают нужно ли сохранять возможность встреч по Zoom, часть членов комитета хотят сохранить Zoom участие в комитете, чтобы дать возможность большему количеству людей присоединиться к обсуждению. Например, Casey Carter рассказывал что он будет участвовать в ближайшей встречи в Kona по Zoom, хотя понятно, что Microsoft не заметила бы командировочных затрат.

Встречи всегда в США проводятся?

Встречи всегда в США проводятся?

Нет.

Но большинство встреч проходило в США.

Вот часть встреч которые были не в США.

2020-02-10 to 15: Prague, Czech Republic

2019-11-04 to 09: Belfast, Northern Ireland

2019-07-15 to 20: Cologne, Germany

2017-07-10 to 15: Toronto, Canada

2016-06-20 to 25: Oulu, Finland

Любопытно, а в России хоть одна встреча проводилась?

Любопытно, а в России хоть одна встреча проводилась?

Если я не слепой то нет.

Можешь само поискать на этой странице, возможно я не заметил: https://isocpp.org/std/meetings-and-participation/upcoming-meetings

Ввёл в поисковой строке браузера слово «Russia», результат: 0/0.

Прикольно. Сравнил ради эксперимента с вот такой шляпой

struct usb_line6 *line6 = (usb_line6 *)(((char*)podhd) + 4);

gcc, код в результате тот же, но без UB :)

clang ругается «applying non-zero offset 4 to null pointer»

https://gcc.godbolt.org/z/d5YahP6c8

Тогда можно переформулировать и сказать, что это проблема не компилятора, а стандарта, т.к. считать вычисление адреса неопределённым поведением, как минимум странно. Доступ по адресу может быть неопределённым поведением, а сохранение адреса в переменную не должно быть таковым.

Нет никакой проблемы ни в стандарте, ни в компиляторах. &foo->bar означает «взять адрес поля bar структуры, на которую ссылается указатель foo». foo-> - это разыменование указателя. То, что в некоторых случаях компилятор делает это просто сложением - это оптимизация. Кстати, оптимизация возможная только от того, что разыменование nullptr - это UB и компилятору разрешено такой вариант не рассматривать. В некоторых случаях такая оптимизация невозможна, например если bar - это ссылка или если bar - поле виртуального базового класса. Тогда &foo->bar перестаёт делаться сложением и компилятор генерирует честное обращение к памяти и получение адреса.