fk0, легенда (22.01.2013 13:55, просмотров: 196) ответил Ксения на Значит в стеке его кто-то потом затирает. Быть не может, чтобы sprinf нуль не добавлял - код смотрите.[ZX]
-
- Почему? "современные стандарты требуют, чтобы представление и требования по выравниванию для void-указателей были теми же, что для указателей на char, что означает взаимозаменяемость этих типов." - Codavr(22.01.2013 14:40, ссылка)
- Нет... sizeof(*(void*)) у конкретного компилятора может быть неизвестно какой, а sizeof(*(char*)) == 1 всегда. У GCC исключение "расширение C", что sizeof в таком случае тоже == 1. Но для других компиляторов не так и бывает, что арифметика над fk0(364 знак., 22.01.2013 17:30)
- sizeof над такими выражениями у конкретного компилятора обязано выдавать ошибку. Codavr(226 знак., 23.01.2013 03:36 - 03:46, ссылка)
- Ошибка должна бы появиться еще раньше - на стадии разыменовывания указателя (void*). Или это не так? - Ксения(23.01.2013 03:40)
- Скорее всего. По крайней мере я такое рисовать точно не стал бы воизбежание недоразумений. По русски это звучит "Хрен знает что по адресу..." - Codavr(23.01.2013 03:48 - 04:07)
- Стихи: "Станем мы всю ночь гуглить, // Чтобы байтик занулить. // Головой об стену биться, // А не лучше ль нам смириться?" :) - Ксения(23.01.2013 03:55)
- :) - Codavr(23.01.2013 03:58)
- Смириться теперь, пожалуй, не получится - перед "молодым коллегой" несмываемый позор :) - Ксения(23.01.2013 04:01)
- :) - Codavr(23.01.2013 03:58)
- Стихи: "Станем мы всю ночь гуглить, // Чтобы байтик занулить. // Головой об стену биться, // А не лучше ль нам смириться?" :) - Ксения(23.01.2013 03:55)
- Скорее всего. По крайней мере я такое рисовать точно не стал бы воизбежание недоразумений. По русски это звучит "Хрен знает что по адресу..." - Codavr(23.01.2013 03:48 - 04:07)
- Ошибка должна бы появиться еще раньше - на стадии разыменовывания указателя (void*). Или это не так? - Ксения(23.01.2013 03:40)
- Стандарт говорит, что sizeof(void) вычислять не положено. А для арифметики (void*) следует приводить к (char*), ессно: стандарт гарантирует, что в этом случае всё будет вменяемо. Если получилось невменяемо, то такой компилятор/проц следует SciFi(34 знак., 22.01.2013 19:05)
- Ссылку на раздел C99, где говорится, что арифметика над void* нормальна? Вот тут утверждают обратное. - fk0(22.01.2013 19:33, ссылка)
- §6.2.6.1 пункт 27 Codavr(1934 знак., 23.01.2013 02:33 - 03:25, ссылка)
- Про арифметику здесь же не сказано. Что должно быть если два void* вычесть? Откуда компилятору знать sizeof в данном случае? - fk0(23.01.2013 11:56)
- Не надо ему знать это. Сейчас некогда рыть стандарт, но там есть пункт, где прописано, что любой указатель обязан быть даблом. Соответственно все правила для арифметики указателей, те же самые что для даблов. - Codavr(23.01.2013 12:02 - 12:08)
- Надоел уже. Нельзя делать арифметику с указателями на void: SciFi(288 знак., 23.01.2013 12:06)
- Этих слов я и ждал. А если в функцию передаётся void* то внутри неё по ошибке арифметику могли сделать. Я вот о чём. - fk0(23.01.2013 12:12)
- ... и получить на выходе компилера трехэтажный мат-перемат. - Codavr(23.01.2013 12:18)
- Неа! В лучшем случае warning, а то и вовсе ничего. Я ж говорю, нарывался (особенно GCC хорош, он в таком случае (void*) как (char*) воспринимает и "маскирует" ошибки), когда в таком случае результат неадекватный. С тех пор ка всю жизнь запомнил. fk0(45 знак., 23.01.2013 14:31)
- И что он в варнинге говорит? "есть опасность неправильно узнать расстояние между двумя объектами расположеными в разных разделах памяти, один в EEPROM, другой в ОЗУ, выберите предпочтительные единицы измерения (дюймы, миллиметры)" - Codavr(23.01.2013 15:31 - 15:34)
- Оба в EEPROM или оба в ОЗУ. Не важно. Важно, что void *p, *q; size_t x=p-q -- здесь в x расстояние в условных sizeof(void), которое может не быть == sizeof(char) как у GCC. - fk0(23.01.2013 17:10)
- Ну не юли. Если одно там, а другое там? - Codavr(23.01.2013 17:18)
- Если одно там, а другое там, то очевидно, полнейший глюкодром. Намекаешь, что оба приводятся к void? А вот фиг, у hitech, например const void* и void* две разные вещи могут быть (24 бита адрес если). И (const void*)0 != NULL вообще из-за 20-го fk0(8 знак., 23.01.2013 17:35)
- Я намекаю, что такое компилер не может как варнинг обрабатывать, если это компилер, а не глюкодром. Это конкрентный еррор. Ну или "вовсе ничего" ушел в себя и не вернулся :) - Codavr(23.01.2013 19:26 - 19:35)
- Кстати, про NULL вспомнилась забавная история: SciFi(300 знак., 23.01.2013 17:58)
- Если одно там, а другое там, то очевидно, полнейший глюкодром. Намекаешь, что оба приводятся к void? А вот фиг, у hitech, например const void* и void* две разные вещи могут быть (24 бита адрес если). И (const void*)0 != NULL вообще из-за 20-го fk0(8 знак., 23.01.2013 17:35)
- Ну не юли. Если одно там, а другое там? - Codavr(23.01.2013 17:18)
- Оба в EEPROM или оба в ОЗУ. Не важно. Важно, что void *p, *q; size_t x=p-q -- здесь в x расстояние в условных sizeof(void), которое может не быть == sizeof(char) как у GCC. - fk0(23.01.2013 17:10)
- Видимо, нельзя полагаться на сообщения компилятора в деле защиты от говнокода. Кстати, есть линты всякие и прочие static code analysis tools. - SciFi(23.01.2013 14:46)
- И что он в варнинге говорит? "есть опасность неправильно узнать расстояние между двумя объектами расположеными в разных разделах памяти, один в EEPROM, другой в ОЗУ, выберите предпочтительные единицы измерения (дюймы, миллиметры)" - Codavr(23.01.2013 15:31 - 15:34)
- Неа! В лучшем случае warning, а то и вовсе ничего. Я ж говорю, нарывался (особенно GCC хорош, он в таком случае (void*) как (char*) воспринимает и "маскирует" ошибки), когда в таком случае результат неадекватный. С тех пор ка всю жизнь запомнил. fk0(45 знак., 23.01.2013 14:31)
- ... и получить на выходе компилера трехэтажный мат-перемат. - Codavr(23.01.2013 12:18)
- И то верно. - Codavr(23.01.2013 12:10)
- Этих слов я и ждал. А если в функцию передаётся void* то внутри неё по ошибке арифметику могли сделать. Я вот о чём. - fk0(23.01.2013 12:12)
- Про арифметику здесь же не сказано. Что должно быть если два void* вычесть? Откуда компилятору знать sizeof в данном случае? - fk0(23.01.2013 11:56)
- Лехко: SciFi(502 знак., 22.01.2013 19:49)
- Это предположение. Мы не знаем, что там арифметика не делается с void. - fk0(22.01.2013 20:34)
- Вообще-то знаем: void - это такой тип, с которым никакая арифметика не делается. Хватит курить траву :-) - SciFi(22.01.2013 22:11)
- Я имею ввиду void* - fk0(22.01.2013 23:02)
- Вообще-то знаем: void - это такой тип, с которым никакая арифметика не делается. Хватит курить траву :-) - SciFi(22.01.2013 22:11)
- Это предположение. Мы не знаем, что там арифметика не делается с void. - fk0(22.01.2013 20:34)
- §6.2.6.1 пункт 27 Codavr(1934 знак., 23.01.2013 02:33 - 03:25, ссылка)
- Ссылку на раздел C99, где говорится, что арифметика над void* нормальна? Вот тут утверждают обратное. - fk0(22.01.2013 19:33, ссылка)
- sizeof над такими выражениями у конкретного компилятора обязано выдавать ошибку. Codavr(226 знак., 23.01.2013 03:36 - 03:46, ссылка)
- Нет... sizeof(*(void*)) у конкретного компилятора может быть неизвестно какой, а sizeof(*(char*)) == 1 всегда. У GCC исключение "расширение C", что sizeof в таком случае тоже == 1. Но для других компиляторов не так и бывает, что арифметика над fk0(364 знак., 22.01.2013 17:30)
- Почему? "современные стандарты требуют, чтобы представление и требования по выравниванию для void-указателей были теми же, что для указателей на char, что означает взаимозаменяемость этих типов." - Codavr(22.01.2013 14:40, ссылка)