g++ баг?

кто-то не умеет считать кол-во элементов в массиве и/или кол-во итераций в цикле

Почитай K&R

Посмотри внимательно на размеры массива же.

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

в x на записывается 0

На code_wtf

В твоем массиве 9x9 = 81 элемент (0..8)x(0..8), элементов с девятками в номере быть не может. Ты просто лезешь за границу массива.

А почему у тебя тогда

int Field1[9][9];

Ну обьясните мне, почему там (0...8)X(0...8), а не (0...9)Х(0...9)? Если не ошибаюсь, это «ошибка последнего столба».

И что, оно не сегфолтится? Странно...

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

А когда у нас x==9 и выполняется Field1[x][y]=0

http://do.rksi.ru/library/courses/demo/tema1_7.dbk

Первая ссылка с гугла. Лень электронную версию фундаментальных трудов искать.

> И что, оно не сегфолтится? Странно...

Потому что защита памяти на x86 происходит страницами. Для 81 элемента типа int массив занимает жалкую сотню байт в памяти. Какова вероятность того, что последний элемент пересечет границы страницы?

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

> Ну обьясните мне

Потому что int x[9] — это объявление массива с 9 элементами: x[0], x[1], x[2], x[3], x[4], x[5], x[6], x[7], x[8].

Домашнее задание: посчитай пальчиком, сколько имеется элементов.

Спасибо. Однако, объясните мне, почему на винде все работает с массивом 9х9? Что за индия?

Благодарю вас за понимание снисходительность.

Интересно, а как это у него в мастдае работало?

> почему на винде все работает с массивом 9х9? Что за индия?

Да ну?

Скрин

Рантайм тебе же выдал сообщение, что ты пишешь в память по адресу, который не выделял. Что тебе еще надо?

Это-то я понял, просто сделал скрин для тех, кто не верил мне насчет невозможности работы этого кода под виндой.

А ошибка тебя не смущает?

> Это-то я понял, просто сделал скрин для тех, кто не верил мне насчет невозможности работы этого кода под виндой.

А ты думал, он вообще запускаться не будет? Считай, что получил сегфолт виндовый.

> Интересно, а как это у него в мастдае работало?

Не знаю, что у него там «работало», а судя по скрину ошибки выхода за границу были.

Меня больше смущает, что ты говоришь, что в Linux этот код не падает в segfault. Должна быть такая же ошибка в рантайме.

Дураку понятно, что ошибка выхода за границу массива будет ближе к его концу, потому что «двумерный массив» в C — это просто одномерный, вытянутый по строкам (в Фортране — по столбцам). «Лишние» элементы будут находиться в конце, поэтому прежде чем получить сегфолт программа успеет вывести на экран большую часть содержимого массива.

Налицо симптомы болезни начинающего программиста: ошибка не у него, а у других. Наверное, все через это проходят.

Записывается. На шаге 9 10 и 10 9, при компиляции без оптимизаций велик шанс, что x располагается именно там.

> Меня больше смущает, что ты говоришь, что в Linux этот код не падает в segfault.

Он падает, но не всегда. Я же писал, что память защищается по страницам, которые размером 4096 байт.

Ошибка рантайма в винде — это скорее всего runtime проверка массива, включенная компилятором для DEBUG-версии (а она, кажется такая по умолчанию в VS)

Не знаю, что у вас налицо, поскольку я всегда сначала у себя ищу ошибку. Однако у меня просто не было других идей насчет этой ошибки. Прошу прощения, если кого-то обидел или оскорбил.

> просто сделал скрин для тех, кто не верил мне насчет невозможности работы этого кода под виндой.

под виндой этот код вообще нахрен не нужен, винда сама обнуляет память для переменных.

Ошибку исправил, все работает корректно. Ошибка заключалась в искривлении мозгов. Всем спасибо.

>поскольку под окнами все отлично работает.

мдя. Я одного не понимаю, почему сразу гонят на компилятор?

>Он падает, но не всегда. Я же писал, что память защищается по страницам, которые размером 4096 байт.

Причём здесь страница? Это автоматический массив.

> Это автоматический массив.

Это статический массив

Это статический массив

Код по ссылке посмотри, прежде чем вызывающе неверную информацию писать.

#include <iostream>
using std::cout;
using std::endl;
int main()
{
	int Field1[10][10];

	for (int x=0;x<10;x++)
	{

	for(int y=0;y<10;y++)
		Field1[x][y]=0;

	}
	cout << "    A B C D E F G H I J\n";
	for (int i=0;i<10;i++)
	{
	cout << i <<": ";

		for(int x=0;x<10;x++)
		
		{int y=0;
		cout <<" "<<Field1[y][x];
		y++;
		}
		cout << endl;
	}

	return 0;
}

Сдается мне, не все так просто. Сейчас перезагрузился в Linux и проверил кое-что. Пока x не достигнет 9, все работает как надо, однако при x=9 начинаются чудеса. y по бесконечному циклу меняет свое значение от 1 до 5 и потом снова начинает с 1. Сдается мне, при модификации памяти за пределами массива мы залезаем в область, где размещается переменная y, что вообще странно. Ведь эта переменная существует только внутри цикла и память под нее должна выделяться случайно. Или я неправильно думаю?

P.S. Из примерно 15 запусков программа зависла одинаковым образом в 100% случаев.

Я конечно понимаю, что в программе ошибка, но такое поведение настораживает. Ладно здесь всего десяток строк, а если будет такое поведение в программе из 10 000 строк? Как там искать ошибку? Ведь даже не понятно, какого рода ошибка происходит.

поэтому это любимый тип ошибок сишников и частично приплюснутых

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

Простите, чье поведение? Мое или проги? :)

Я могу ошибаться, но разве у меня динамический массив? Кол-во элементов же не меняется.

Проверил на gcc. Те же яйца, только в профиль. Печально. Вот так, наверное, и появляются легенды о плавающих багах, которые не могут поймать годами.

Массив выделен на стеке. Индексация внутри массива идёт вверх по памяти, а стек растёт вниз. Значит вылезая за пределы массива, мы затираем расположенные выше переменные если они есть,, затем сохраненные регистры, адрес возврата и уродуем предыдущий фрейм — в зависимости от того, насколько далеко вылезли.

Так что unanimous не прав, когда относительно данного массива пишет:

что память защищается по страницам, которые размером 4096 байт.

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

Это фигня. Вот обращение по адресу нулевой указатель + некоторое довольно большое смещение у меня давало гораздо более веселые и неуловимые эффекты. :)

и да это ошибка не gcc и баг понятен, неправильная работа с памятью

Для ясности:

s/Сегфолта не будет./Сегфолта в момент buffer overrun от обращения к невыделенной памяти не будет./

Понятно, что позже сегфолт может вылететь запросто.