Rust 1.7

а вот рефлексия, например, в Java это то, что используется во все поля.

Да я не спорю, что штука полезная (бывает). В «джавовском виде» рефлексии в расте явно не будет, но тот же С++ живёт без рефлексии вообще. А вот на этапе компиляции можно через макросы изобразить, если так сильно хочется.

И еще на тему рефакторинга:

Не понимаю какую мысль ты донести хочешь.

thread '<main>' has overflowed its stack
playpen: application terminated abnormally with signal 11 (Segmentation fault)

Дефолтный размер стака у большинства дистров линукса 8Мб, это нормальное поведение.

это нормальное поведение.

Нормальное поведение для языка, который гордо заявляет «guaranteed memory safety», - не напороться на Segmentation fault, а, например, бросить исключение как в Java.

для языка, который гордо заявляет «guaranteed memory safety»

У тебя какое-то свое понимание memory safety.

У тебя какое-то свое понимание memory safety.

А у тебя какое-то свое понимание segmentation fault. Очевидно код на Rust полез за пределы стека.

Очевидно код на Rust полез за пределы стека.

Я понимаю, что случилось. Это можно считать косяком, но это не нарушение memory safety.

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

Прикол, супербезопасный конпелятор не просек переполнение стека

А как компилятор мог это просечь - он оракул?

Ну судя по пафосу ржавых верунов в святой конпелятор, да.

судя по пафосу ржавых верунов

Ты опять слушаешь голоса в голове.

А как компилятор мог это просечь - он оракул?

https://en.wikipedia.org/wiki/AddressSanitizer#Stack-buffer-overflow

Хотя это не тот пример, но переполнение стека он тоже ловит аналогично.

Это другая вещь, и это рантайм.

и это рантайм

Ну и ладно, всяко лучше чем попробовать записать по адресу, а там будь что будет.

Я и говорю - можно считать косяком. Но я не вижу нарушения memory safety.

Но я не вижу нарушения memory safety.

https://en.wikipedia.org/wiki/Memory_safety

Stack exhaustion - occurs when a program runs out of stack space, typically because of too deep recursion. A guard page typically halts the program, preventing memory corruption, but functions with large stack frames may bypass the page.

https://en.wikipedia.org/wiki/Memory_safety

Out-of-memory errors that do not halt the program can lead to violations of memory safety

Но программа была halted, поэтому ошибка не привела к violation of memory safety.

typically halts the program

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

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

https://en.wikipedia.org/wiki/AddressSanitizer#Stack-buffer-overflow

1) Тут вообще используется адресация за пределом массива, от чего раст как раз таки защищает.

2) Тут ошибка во время чтения, а не аллокация как в примере с ошибкой раста.

3) Это ошибка в рантайме, а не при компиляции. Собственно в чем разница?

Нормальное поведение для языка, который гордо заявляет «guaranteed memory safety», - не напороться на Segmentation fault

Переполнение стака, так же как и паникующий unwrap - прямой признак ошибки в программе. Такая программа и не должна работать.

Но программа была halted, поэтому ошибка не привела к violation of memory safety.

Это не заслуга Rust:

«A guard page typically halts the program, preventing memory corruption, but functions with large stack frames may bypass the page.»

Это раз. Во-вторых берем:

fn main() {
    let x = [0u8; 1024 * 1024];
}

Смотрим выхлоп:

.Ltmp0:
	.cfi_def_cfa_offset 16
.Ltmp1:
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
.Ltmp2:
	.cfi_def_cfa_register %rbp
	subq	$1048464, %rsp
	xorl	%eax, %eax
	movl	%eax, %ecx
	leaq	-1048576(%rbp), %rdx
	movq	%rdx, -1048584(%rbp)
	movq	%rcx, -1048592(%rbp)
.LBB0_1:
	movq	-1048592(%rbp), %rax
	movq	-1048584(%rbp), %rcx
	movb	$0, (%rcx,%rax)
	addq	$1, %rax
	cmpq	$1048576, %rax
	movq	%rax, -1048592(%rbp)
	jb	.LBB0_1
	.loc	1 3 0 prologue_end
.Ltmp3:
	addq	$1048464, %rsp
	popq	%rbp
	retq
.Ltmp4:

Оба-на, при инициализации код начинает писать значения с того адреса, с какого мы захотим, сразу перескочив и весь стек и «guard page».

Переполнение стака, так же как и паникующий unwrap - прямой признак ошибки в программе. Такая программа и не должна работать.

Я вижу у Rust яже появилась своя минисекта.

Но программа была halted, поэтому ошибка не привела к violation of memory safety.

Это не заслуга Rust

Memory safety не нарушена, но твое особое мнение занесено в протокол.

Я вижу у Rust яже появилась своя минисекта.

Зависть - плохое чувство.

Memory safety не нарушена

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

Зависть - плохое чувство.

Было бы к чему.

См. выше.

Так бы и сказал, что ассемблер - слишком сложно, и вообще много букв, не осилил.

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

Это ошибка программиста. Если ты выделяешь 100500 элементов на стеке, будь добр, подгони стек под эти требования.

В семантике языка, Box::new([2i64; N]) означает:

• Выделить на стеке size_of::<i64>() * N
• Заполнить его 2
• Выделить в куче size_of::<i64>() * N
• Перенести значения из стека

Так уж и быть, в общем расскажу, что происходит. Стек на x86 растет вниз, а не вверх. Потому, когда Rust выделяет память под массив он уменьшает адрес на размер массива, пропуская и стек и «guard page». После чего идет инициализация значений массива. Только идет она не сверху-вниз как стек, чтоб сразу напороться на guard page и откинуться, а снизу-вверх. Т.е. мы можем произвести запись как угодно далеко за пределами стека. Да, после этого мы таки напоремся на segfault, но до этого мы некоторое время успешно будем портить память. Со всеми возможными последствиями.

Это ошибка программиста.

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

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

Ну ладно, ладно. Rust совсем не безопасный. Сколько стека то надо? 1 Мб? Мало? Ну давай тогда 1Гб? Опять мало? Ну давай тогда всю память под стек, тогда точно не упадёт.

Это не заслуга Rust:

Ну, не совсем:
https://github.com/rust-lang/rust/pull/27338
https://github.com/rust-lang/rust/issues/16012

Хотя да, недоработка.
Не помешала бы фича типа #[fixed_stack_size(size)]

Ну ладно, ладно. Rust совсем не безопасный. Сколько стека то надо? 1 Мб? Мало? Ну давай тогда 1Гб? Опять мало? Ну давай тогда всю память под стек, тогда точно не упадёт.

Нисколько не надо, нужна проверка текущего.

https://msdn.microsoft.com/ru-ru/library/system.stackoverflowexception(v=vs.1...

Так уж и быть

Как будто тебя кто-то о чем-то просил.

Как будто тебя кто-то о чем-то просил.

Пожалуйста.

Пожалуйста.

Не за что.

Нисколько не надо, нужна проверка текущего.

Так это есть.

thread '<main>' has overflowed its stack
fatal runtime error: stack overflow

Раньше был __morestack, но отказались, т.к. негативно сказывается на производительности.

Как ты будет проверять каждый указатель? Как это скажется на производительности?

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

Как ты будет проверять каждый указатель? Как это скажется на производительности?

Зачем каждый?

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

Об этом может побеспокоиться и рантайм.

Об этом может побеспокоиться и рантайм.

Ну да, а потом рантайм позаботится и об управлением памятью... А стой...

Об этом может побеспокоиться и рантайм.

Ну да, а потом рантайм позаботится и об управлением памятью...

А потом он убьет твою собаку.

Не поленился, посмотрел на чем крашится.

http://pastexen.com/i/UJETCjBY3U.png

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

Так это есть.
thread '<main>' has overflowed its stack
fatal runtime error: stack overflow

У меня rust такое пишет, только если устроить бесконечную рекурсию. Со слишком большим массивом тупо молча вываливается в сегфолт.

А потом он убьет твою собаку.

Я же не зову его на помощь. Пусть переживают те, кто его зовёт.

Пусть переживают те, кто его зовёт.

Они как раз не переживают ни о собаке, ни об управлении памятью.

Они как раз не переживают ни о собаке, ни об управлении памятью.

Это неправда, собаку жалко.

Не переживай, рантайм ее не убьет. И памятью управлять тоже не будет.

У меня rust такое пишет, только если устроить бесконечную рекурсию. Со слишком большим массивом тупо молча вываливается в сегфолт.

В конце стека страница, обращение к которой и означает переполнение. Если массив больше 4Кб, то он её просто перескочит. Потом Rust попытается попортить память за пределами стека + 4Кб. Если она не отображена, то будет ошибка сегментации. Если отображена, то в любом (если не писать uninitialized) случае наткнётся на страницу и будет переполнение стека как в рекурсии.

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

Когда люди говорят о спасительном рефакторинге, в подавляющем большинстве случаев, ИМХО, он либо ещё не нужен, либо уже не нужен.

В первом случае на лицо каргокультизм, в втором — быдлокодерство (лучше клин-рум, чем разбор спагетти).

И да, сдается мне, что зависимость от рефакторинга есть последствия ООП гойловного моска. Вот цитата Степанова на эту тему:

Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле.

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

Следующий раз попробуй донести мысль о том, что нужно быть богатым и здоровым.

в подавляющем большинстве случаев

Мде.

Следующий раз попробуй донести мысль о том, что нужно быть богатым и здоровым.

Так без меня есть кому её доносить :) Включи телевизор или там вконтактик открой, там отовсюду общество потребления лезетXDXDXDXD

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

Следующий раз попробуй донести мысль о том, что нужно быть богатым и здоровым.

Так без меня есть кому её доносить :)

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