The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]



"Для Linux и Redox представлена реализация Libc на языке Rust"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от opennews (??) on 09-Мрт-18, 09:51 
Разработчики операционной системы Redox (https://www.opennet.ru/opennews/art.shtml?num=46919), развиваемой с использованием языка Rust и применяющий концепцию микроядра, представили (https://www.redox-os.org/news/this-week-in-redox-36/) проект по созданию собственной стандартной Си-библиотеки Relibc (https://github.com/redox-os/relibc). Код проекта написан на языке Rust и распространяется (https://github.com/redox-os/relibc) под лицензией MIT. Relibc позиционируется как переносимая реализация  стандартной библиотеки Си, соответствующая стандарту POSIX и способная работать не только в Redox, но и в дистрибутивах на базе ядра Linux.

Работа над проектом началась 2 марта и функциональность библиотеки пока сильно ограничено, но к разработке уже подключилось 5 участников и проект активно развивается. Ранее в Redox в качестве стандартной библиотеки применялся форк (https://github.com/redox-os/newlib) библиотеки newlib (https://github.com/redox-os/newlib) от проекта Сygwin, но он не устраивал разработчиков с точки зрения безопасности и  кросс-платформенности.

Использование языка Rust позволяет избавиться от свойственных языку Си усложнений при организации работы с памятью  и задействовать при разработке предоставляемые языком Rust средства по обеспечению безопасного программирования. Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.

URL: https://www.redox-os.org/news/this-week-in-redox-36/
Новость: https://www.opennet.ru/opennews/art.shtml?num=48226

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Аноним (??) on 09-Мрт-18, 09:51 
Давайте теперь посмотрим на тесты скорости по сравнению с обычной библиотекой :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Для Linux и Redox представлена реализация Libc на языке Rust"  +18 +/
Сообщение от A.Stahl (ok) on 09-Мрт-18, 10:19 
Зачем? Оно не ради скорости делалось. А ради... блин, я х.з. ради чего, но точно не ради какого-либо практического применения.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Для Linux и Redox представлена реализация Libc на языке Rust"  –3 +/
Сообщение от Аноним (??) on 09-Мрт-18, 10:31 
Для того чтобы показать, что уменьшение скорости выполнения на 10% даже если код абсолютно безопасен, на фиг никому не нужно из компаний, потому что любое уменьшение производительности там, где до этого использовался C - это миллионы американских долларов.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

8. "Для Linux и Redox представлена реализация Libc на языке Rust"  –2 +/
Сообщение от Bvz on 09-Мрт-18, 10:39 
А скорость всегда будет падать?
А если отключить всякие проверки на выход за границы, то оно станет такое же быстрое? (ну небезопасное)
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Аноним (??) on 09-Мрт-18, 10:44 
> А скорость всегда будет падать?
> А если отключить всякие проверки на выход за границы, то оно станет
> такое же быстрое? (ну небезопасное)

Если отключить проверки, тогда зачем нужен раст?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

14. "Для Linux и Redox представлена реализация Libc на языке Rust"  +3 +/
Сообщение от Аноним (??) on 09-Мрт-18, 11:02 
В Rust все проверки при компиляции проходят.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

15. "Для Linux и Redox представлена реализация Libc на языке Rust"  +5 +/
Сообщение от A.Stahl (ok) on 09-Мрт-18, 11:08 
Тогда насколько они эффективны? Что-то мне подсказывает, что 99% выходов за пределы массива проходит в циклах и т.п. И что тут можно анализировать на этапе компиляции?
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

41. "Для Linux и Redox представлена реализация Libc на языке Rust"  –2 +/
Сообщение от Аноним (??) on 09-Мрт-18, 16:28 
> Что-то мне подсказывает, что 99% выходов за пределы
> массива проходит в циклах и т.п. И что тут можно анализировать на этапе компиляции?

Спасибо за Мудрость и приоткрытие Изначальных Законов Вселенной!
Хотелось бы знать, видели ли Вы хоть раз суслика в норе и можете изобразить его в мельчайших анатомических подробностях? Если нет, значит ли это отсутствие сусликов в природе вообще или же только видов, проживающих в норах?

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

68. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от 0xd34df00d (??) on 10-Мрт-18, 05:12 
Доказать, что индекс всегда внутри правильного диапазона, например. Про rust не знаю, но в каком-нибудь Idris это довольно легко.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

71. "Для Linux и Redox представлена реализация Libc на языке Rust"  –4 +/
Сообщение от A.Stahl (ok) on 10-Мрт-18, 10:02 
Это практически всегда невозможно. А в тех тривиальных случаях когда такая возможность есть, проблема практически не возникает.
Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

16. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Аноним (??) on 09-Мрт-18, 11:20 
>В Rust все проверки при компиляции проходят.

ну это как вставить cppcheck какой-нибудь в препроцессор  :)

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

20. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Аноним (??) on 09-Мрт-18, 12:07 
Замечательно.

Теперь продолжите логическую цепочку. Почему " cppcheck какой-нибудь " не эффективен для C++ и C ? Потому что язык слишком лоялен к выстрелам в ногу. Теперь делаем язык, такой, что он эффективно интегрирует некий langcheck для проверок во время компиляций. Вот Rust - он по такому принципу сделан

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

21. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 12:12 
>Почему " cppcheck какой-нибудь " не эффективен для C++ и C ?

Как это не эффективен?

Просто язык не лоялен к тем кто делает все наполовину. Сделал char* t = malloc(15* sizeof(char*)); почему не делаешь free(t) ?

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

31. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 14:48 
> Просто язык не лоялен к тем кто делает все наполовину. Сделал char*
> t = malloc(15* sizeof(char*)); почему не делаешь free(t) ?

На раз поймается и valgrind и asan.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

27. "Для Linux и Redox представлена реализация Libc на языке Rust"  –2 +/
Сообщение от Crazy Alex (ok) on 09-Мрт-18, 13:31 
Он (точнее, более живые анализаторы) очень даже эффективен для отлова отхода от современных плюсов (с которых, кстати, "безопасные" концепты раста во многом и содраны).
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

75. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Nexmean on 10-Мрт-18, 14:54 
Лайфтаймы, владение и заимствование?
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

87. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Vkni (ok) on 11-Мрт-18, 02:26 
> Лайфтаймы, владение и заимствование?

unique_ptr или auto_ptr + RAII.

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

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

88. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от 0xd34df00d (??) on 11-Мрт-18, 02:40 
> unique_ptr

Только если вы при этом ещё запретите get и ссылки на unique_ptr, что вряд ли реализуемо на практике. Владение и заимствование — это не только про то, кто отвечает за удаление объекта, но и про то, кто в него в данный момент может писать и кто может из него читать.

Нельзя линейные (на самом деле аффинные) типы эмулировать unique_ptr'ом, увы.

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

89. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Vkni (ok) on 11-Мрт-18, 06:16 
О! Спасибо, чё-то не задумывался об этом. И тут, значит, уши ML-ей (конкретно - Clean) торчат.

Я как-то под эти разговоры, что дескать это С++-v2, совершенно упустил этот момент.

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

66. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Alex (??) on 10-Мрт-18, 04:13 
Выход за границы массива бросает исключение в расте. Проверка в рантайм.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

74. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Ordu email(ok) on 10-Мрт-18, 12:51 
> Выход за границы массива бросает исключение в расте.

Бросает, да.

> Проверка в рантайм.

Да ладно. Почему же в рантайме, если её можно выполнить статически в compile-time?

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

79. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от pavlinux (ok) on 10-Мрт-18, 19:21 
> В Rust все проверки при компиляции проходят.

Он читает мысли?

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

94. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от bOOster (ok) on 11-Мрт-18, 17:44 
Ну точно, так же как и в JAVA.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

113. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от dq0s4y71 (ok) on 13-Мрт-18, 14:52 
Сколько ни изобретай свой собственный велосипед с треугольными колёсами, всё равно придётся осилить грёбаные указатели. Мир несправедлив.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Для Linux и Redox представлена реализация Libc на языке Rust"  +8 +/
Сообщение от Sunderland93 (ok) on 09-Мрт-18, 10:29 
Давайте. Но только когда проект дорастёт до первого стабильного релиза.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

98. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Аноним (??) on 12-Мрт-18, 12:16 
Это когда версия будет 248.0.3?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

100. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Iaaa (ok) on 12-Мрт-18, 13:05 
Через еще одну неделю.
Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

9. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Аноним (??) on 09-Мрт-18, 10:39 
Скорее всего всё ок, т.к. в rust управление памятью не создаёт оверхеда (все проверки статические, во время компиляции).
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

23. "Для Linux и Redox представлена реализация Libc на языке Rust"  +3 +/
Сообщение от Аноним (??) on 09-Мрт-18, 12:38 
Даже для динамических массивов? :) Ну, ребята, ну что же это такое. Почему не разбирающиеся в чем либо лезут комментировать?
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

32. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от VladSh on 09-Мрт-18, 14:54 
То есть проверок для динамических массивов в рантайме лучше не делать?
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

33. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 15:07 
Мы же про статический анализатор динамических массивов разве нет? :)
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

35. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от pda on 09-Мрт-18, 15:08 
Иногда и для них. Rust предоставляет достаточно информации llvm, чтобы тот мог удалять проверку диапазона в некоторых случаях. Например (насколько я помню), когда вы делаете цикл по неизменяемому объекту (например неизменяемой ссылке) и только что получили длину массива, llvm может понять, что вы никогда не выйдите за границу диапазона и удалить проверку.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

53. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от angra (ok) on 09-Мрт-18, 21:12 
А если я в цикле присвою счетчику другое значение? А если обращусь к a[i+1] на последней итерации?
Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

60. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 22:31 
Дада, это всё очень просто отлавливается компилятором.
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

63. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от angra (ok) on 10-Мрт-18, 00:53 
Разве что в самых простейших случаях, типа тела цикла из одного выражения. При наличии других переменных, ветвлений и вызовов функций всё становится совсем не простым для компилятора.
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

65. "Для Linux и Redox представлена реализация Libc на языке Rust"  +3 +/
Сообщение от Ordu email(ok) on 10-Мрт-18, 01:58 
> А если я в цикле присвою счетчику другое значение?

    for mut i in 0..10 {
        println!("{}", i);
        i += 1;
    }
результат компиляции:
warning: value assigned to `i` is never read
--> tmp.rs:4:9
  |
4 |         i += 1;
  |         ^
  |
  = note: #[warn(unused_assignments)] on by default

Я поясню на всякий случай: изменение i на итерации цикла никак не влияет на то, с какими значениями i будет вызвано тело цикла.

> А если обращусь к a[i+1] на последней итерации?

И как это будет выглядеть? Может так?

for i in 0..a.len() {
    if i == a.len() - 1 {
        println!("{}", a[i+1]);
    }
}

Или как-то интереснее? В приведённом варианте, компилятор, раскрывая a[i+1], заинлайнит метод a.index(i+1), и таким образом вставит в код проверку i+1<a.len(), а дальше llvm, найдя эту проверку, заметит, что проверка не нужна, потому что если выполняется i==a.len()-1, то i+1<a.len() гарантированно не выполняется, значит можно ругнуться о dead_code и вышвырнуть из кода println!, а затем и весь if тоже, а затем ещё и цикл, потому что это код не имеющий побочных эффектов.

Если мы просто будем обращаться к a[i+1], без всяких условий, то тут есть два варианта. Если цикл пойдёт по диапазону 0..a.len()-1, то проверка внутри цикла будет выкинута оптимизатором как ненужная. Если цикл пойдёт по большему диапазону, то проверка останется, потому что оптимизатор не сможет доказать, что она не нужная, и в этом случае мы собственно и получим панику на этапе выполнения.

А если компилятор для цикла 0..a.len() сможет вычислить точный размер a на этапе компиляции, то, я подозреваю, он сделает цикл по диапазону 0..a.len()-1, который не будет содержать проверок, а после цикла вызовет panic! (тот который должен был случится, в силу выхода индекса за границы массива). То есть там будет одна проверка на весь код, и эта проверка будет связана с организацией цикла. Если конечно компилятор не развернёт этот цикл, так чтобы он превратился бы в линейный код.

Все эти вещи компиляторы C тоже умеют делать не хуже чем компилятор rust'а, вы можете поизучать эти возможности оптимизаторов даже не связываясь с rust'ом, для этого достаточно освоить опции -S, -fverbose-asm, и ещё полезно подчастую -Os вставлять вместо -O2 -- так ассемблерный выхлоп получается понятнее человеку, правда это искажает результаты оптимизации. И я очень рекомендую поизучать их, потому что использование C без знания того, как компилятор генерит код -- это... я не знаю, как это назвать, но это совершенно неправильно. Так не выйдет писать хороший код на C, можно писать что-нибудь в стиле exim, но не хороший код.

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

67. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от angra (ok) on 10-Мрт-18, 04:43 
Ох уж эти титеретики
fn main() {
    let a: [i32;5]=[1,2,3,4,5];
    for i in 0..a.len() {
        if i == a.len() - 1 {
            println!("{}", a[i+1]);
        }
    }
}

Compiling playground v0.0.1 (file:///playground)
    Finished release [optimized] target(s) in 0.59 secs
     Running `target/release/playground`
thread 'main' panicked at 'index out of bounds: the len is 5 but the index is 5', /checkout/src/libcore/slice/mod.rs:830:10
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

72. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Ordu email(ok) on 10-Мрт-18, 12:09 
И? Вы хотите сказать, что проверка осталась и выполнялась на каждой итерации цикла? Что вызов panic! не был вынесен за пределы цикла? Или что вы хотите этим сказать?
Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

73. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Ordu email(ok) on 10-Мрт-18, 12:23 
    .type    _ZN3tmp4main17hd307395e913df02cE,@function
_ZN3tmp4main17hd307395e913df02cE:
    .cfi_startproc
    pushq    %rax
.Lcfi0:
    .cfi_def_cfa_offset 16
    leaq    panic_bounds_check_loc.1(%rip), %rdi
    movl    $5, %esi
    movl    $5, %edx
    callq    _ZN4core9panicking18panic_bounds_check17ha7f06c957d05f2e3E@PLT
    ud2
.Lfunc_end0:
    .size    _ZN3tmp4main17hd307395e913df02cE, .Lfunc_end0-_ZN3tmp4main17hd307395e913df02cE
    .cfi_endproc

Я даже не поленился и посмотрел. С -C opt-level=2 (в коде приведённом выше) цикл был выкинут вообще, и вся функция была оптимизирована к вызову паники. С opt-level=s почему-то остался пустой цикл, а вызов паники был вынесен за пределы.

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

80. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от Vkni (ok) on 10-Мрт-18, 21:38 
> и вся функция была оптимизирована к
> вызову паники. С opt-level=s почему-то остался пустой цикл, а вызов паники
> был вынесен за пределы.

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

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

85. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Ordu email(ok) on 10-Мрт-18, 23:00 
>> и вся функция была оптимизирована к
>> вызову паники. С opt-level=s почему-то остался пустой цикл, а вызов паники
>> был вынесен за пределы.
> С одной стороны это круто,

Сегодня это уже не круто, это нормальное поведение для любого уважающего себя компилятора. Собственно всё это даже не столько заслуга rust, сколько llvm. Я говорю: и clang, и gcc проворачивают то же самое с C'шным кодом. Если этот код переписать на C, добавив туда явную проверку на выход за границы массива и вызов функции panic, если это случается, то и clang, и gcc сгенерят практически такой же код, может быть даже ровно такой же байт в байт.

> с другой - компилятор явно недоделан,

Я бы сказал, что язык недоделан, а не компилятор. Но, может быть, это без разницы.

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

Можно анализировать статически всё что угодно, но зачем? Какие, например, доп. результаты мы можем получить при анализе машинного кода?

Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

86. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Vkni (ok) on 11-Мрт-18, 02:24 
> Собственно всё это даже не столько заслуга rust, сколько llvm.

Ох.

> Можно анализировать статически всё что угодно, но зачем? Какие, например, доп. результаты мы можем получить при анализе машинного кода?

После большого количества inline'ов и всяких мудрых мыслей может получиться, что функция редуцируется до panic, как тут, что довольно неприятно.

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

91. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Ordu email(ok) on 11-Мрт-18, 10:25 
>> Можно анализировать статически всё что угодно, но зачем? Какие, например, доп. результаты мы можем получить при анализе машинного кода?
> После большого количества inline'ов и всяких мудрых мыслей может получиться, что функция
> редуцируется до panic, как тут, что довольно неприятно.

Такие вещи будет сложно отловить анализируя чисто машинный код, всё равно придётся сравнивать семантику описанную в сорце с семантикой машинного кода. Поэтому статические анализаторы сами не дураки проделать работу компилятора и редуцировать код, выкинув оттуда всё то, что не несёт смысловой нагрузки. Собственно, а как иначе можно вычислить условие которое всегда выполняется или код, который никогда не выполняется?

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

82. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от Аноним (??) on 10-Мрт-18, 22:21 
>  .type _ZN3tmp4main17hd307395e913df02cE,@function
> _ZN3tmp4main17hd307395e913df02cE:

О да. Вот что они взяли из плюсов - так это вот это. А в сях таки в этих случаях нормальные названия функций вместо этого птичьего чирикания. Что сиииильно упрощает разборку с программой :). Как угодно но читать в инстурментах вот такое птичье чирикание - желания никакого.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

101. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от Iaaa (ok) on 12-Мрт-18, 13:13 
> Как угодно но читать в инстурментах вот такое птичье чирикание -
> желания никакого.

Что, так сложно накидать скрипт, который будет парсить такой вывод и деманглить имена?

Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

107. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Аноним84701 (ok) on 12-Мрт-18, 15:29 
>> Как угодно но читать в инстурментах вот такое птичье чирикание -
>> желания никакого.
> Что, так сложно накидать скрипт, который будет парсить такой вывод и деманглить
> имена?

c++filt вполне себе справляется;
(Код из #73)


% cat /tmp/tst
   .type    _ZN3tmp4main17hd307395e913df02cE,@function
_ZN3tmp4main17hd307395e913df02cE:
    .cfi_startproc
    pushq    %rax
.Lcfi0:
    .cfi_def_cfa_offset 16
    leaq    panic_bounds_check_loc.1(%rip), %rdi
    movl    $5, %esi
    movl    $5, %edx
    callq    _ZN4core9panicking18panic_bounds_check17ha7f06c957d05f2e3E@PLT
    ud2
.Lfunc_end0:
    .size    _ZN3tmp4main17hd307395e913df02cE, .Lfunc_end0-_ZN3tmp4main17hd307395e913df02cE
    .cfi_endproc


% c++filt < /tmp/tst
   .type    tmp::main::hd307395e913df02c,@function
tmp::main::hd307395e913df02c:
    .cfi_startproc
    pushq    %rax
.Lcfi0:
    .cfi_def_cfa_offset 16
    leaq    panic_bounds_check_loc.1(%rip), %rdi
    movl    $5, %esi
    movl    $5, %edx
    callq    core::panicking::panic_bounds_check::ha7f06c957d05f2e3@PLT
    ud2
.Lfunc_end0:
    .size    tmp::main::hd307395e913df02c, .Lfunc_end0-tmp::main::hd307395e913df02c
    .cfi_endproc

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

108. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Iaaa (ok) on 12-Мрт-18, 16:37 
Не пользуюсь, но все равно - большое спасибо. Когда-нибудь точно пригодится.
Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

77. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от angra (ok) on 10-Мрт-18, 18:10 
Я хочу сказать ровно одно, сказанное титеретиком не выдержало проверки практикой. Но так как ты страдаешь избирательной амнезией, то я процитирую, что именно ты сказал: "гарантированно не выполняется, значит можно ругнуться о dead_code и вышвырнуть из кода println!, а затем и весь if тоже, а затем ещё и цикл, потому что это код не имеющий побочных эффектов."
Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

78. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Ordu email(ok) on 10-Мрт-18, 18:32 
> Но
> так как ты страдаешь избирательной амнезией, то я процитирую, что именно
> ты сказал: "гарантированно не выполняется, значит можно ругнуться о dead_code и
> вышвырнуть из кода println!, а затем и весь if тоже, а
> затем ещё и цикл, потому что это код не имеющий побочных
> эффектов."

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

Ещё какие-нибудь возражения у "практика" есть?

Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

48. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 18:16 
> Скорее всего всё ок, т.к. в rust управление памятью не создаёт оверхеда
> (все проверки статические, во время компиляции).

И как статически проверить конкатенацию 2 строк вводимых юзером, например?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

6. "Для Linux и Redox представлена реализация Libc на языке Rust"  +8 +/
Сообщение от фывфыв on 09-Мрт-18, 10:32 
> Код проекта написан на языке Rust

Бла-бла-бла, математика использует openlibm, а оно на C.
Алокаторы памяти и прочие низкоуровневые вещи регулярно пестрят unsafe блоками, что автоматически нивелирует все "плюшки" Rust'а.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 10:36 
Есть примеры?
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

11. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Аноним (??) on 09-Мрт-18, 10:51 
Модуль реализации строк посмотри.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

12. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 10:51 
> Есть примеры?

https://github.com/redox-os/relibc/search?utf8=%E2%...

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

18. "Для Linux и Redox представлена реализация Libc на языке Rust"  +11 +/
Сообщение от lfx (ok) on 09-Мрт-18, 11:33 
Лучше молчи... Когда я сказал что без unsafe на rust далеко не уедешь, любители смузи меня тапками забросали. Им что то объяснять себе дороже.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

34. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Аноним (??) on 09-Мрт-18, 15:08 
> тапками

кедами

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

70. "Для Linux и Redox представлена реализация Libc на языке Rust"  +3 +/
Сообщение от Аноним (??) on 10-Мрт-18, 09:36 
Вот и выросло поколение школьников, которое думает, что кеды придумали хипстеры...
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

13. "Для Linux и Redox представлена реализация Libc на языке Rust"  –7 +/
Сообщение от Аноним (??) on 09-Мрт-18, 10:53 
Вообще касательно самого языка.
Идея хорошая, только зря они его назвали "rust".

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

В итоге все заглохнет. И проекты на нем тоже. Будет еще хуже, чем с D.
А жаль, был бы неплохой язык, если бы не название.

Это еще как с OS Fiasco.
Ой, оказывается это такая итальянская бутылка!
А в итоге кто ее использует?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

22. "Для Linux и Redox представлена реализация Libc на языке Rust"  –2 +/
Сообщение от кверти (ok) on 09-Мрт-18, 12:25 
>OS Fiasco

Это когда FreeBSD переименовать успели?

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

25. "Для Linux и Redox представлена реализация Libc на языке Rust"  +3 +/
Сообщение от Аноним (??) on 09-Мрт-18, 12:50 
У вас фиаско с FreeBSD?


Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

24. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 12:46 
Надо ([кому?]) переписать игру Rust на язык Rust.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

37. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от pda on 09-Мрт-18, 15:20 
И что? Похоже вы как и многие не правильно понимают назначение unsafe (так же как многие не правильно понимают значение "свобода слова" или "независимая пресса" и лепят в них собственные определение. простите за политоту.).

Unsafe не что-то плохое в rust, в вполне сознательно сделанная вещь. Она позволяет создавать эффективные реализации, предоставляя к ним безопасный интерфейс для всей остальной программы. Если вы например написали реализацию двунаправленного списка при помощи unsafe, то очевидно, что вам придётся покрыть её изрядным количеством тестов, чтобы убедиться, что во всех возможных случаях код будет работать правильно, а в указателях никогда не окажется некорректных значений.

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

Хорошим примером такого подхода является языки C/C++, где программисты регулярно лажают от лени или усталости забывая вставлять проверку указателей на каждом шагу или делая это неправильно.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

54. "Для Linux и Redox представлена реализация Libc на языке Rust"  –2 +/
Сообщение от sadasd on 09-Мрт-18, 21:24 
О чем и речь, что в коде там дофига unsafe и смысла писать на Rust нет.

А вообще, еще до Rust'а были "безопасные" варианты C, Cyclon например.
Да и вообще, к тому-же GCC / Clang приписать пару пачку проверок и поставить их в -Werror.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

62. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Тот же Аноним on 10-Мрт-18, 00:31 
А -fpermissive можно? А то на с++ такое бывает...

блаблабла предупреждение: декларация ничего не описывает [-fpermissive]
#   define off_t long
Да можно typedef-ом, но за что препроцессор?

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

81. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Vkni (ok) on 10-Мрт-18, 21:48 
> О чем и речь, что в коде там дофига unsafe и смысла
> писать на Rust нет.

Смысла есть - во-первых, внутре unsafe тоже rust, а не C. Во-вторых, ошибки бывают разные, причём большая часть ни к каким segfault'ам не приводит. В Питоне, например, довольно тяжело сделать выход за границы выделенной интерпретатору памяти, однако написать программу в 1000 строк без дюжины ошибок совершенно невозможно.

Rust'овские владения, частичный вывод типов, неизменяемые объекты по-умолчанию и т.д. отсекают ряд ошибок, в том числе и такие, что ни к каким падения не приводят, а ведут к неправильным результатам.

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

55. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от _ (??) on 09-Мрт-18, 21:46 
>Unsafe не что-то плохое в rust, в вполне сознательно сделанная вещь. Она позволяет создавать

... хоть как то работающие программы :) Не надо песен, у нас их тоже есть!

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

Наивняк! :) Это уже было. Да - Java promise :) Чем всё кончилось? Покрывают тестами __всё__! И это правильно, ибо нефиг. И у вас тоже самое будет, всё суета сует :-)

>Хорошим примером такого подхода является языки C/C++, где программисты регулярно лажают от лени или усталости забывая вставлять проверку

Оу-е бэйби! А ржавчики будут кодячить без усталости и лени! :-))))) Гив ми море! :)

Может оно и взлетит, но взлетит вопреки. Ибо нафиг оно - до сих пор не очевидно.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

64. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от pda on 10-Мрт-18, 01:07 
Вы так ничего и не поняли.

> Это уже было. Да - Java promise :)

Бессмысленное сравнение. В Java (визитной карточкой которого является NullPointerException) такае навеска - как фаервол с политикой "пропускать" и попытка сделать надёжным, путём кучи запрещающих правил. Unsafe это необходимая дырка в запрещающем фаерволе. Rust потому и бесит многих, что похож на фаервол с политикой "запрещать".

> Покрывают тестами __всё__!

Я не знаю как там в Java, не видел много Java, но судя по регулярным статьям о PVSStudio - нет, не покрывают. Хуже того, некоторые сознательно даже кое-каких проверок не вставляют, рассчитывая, что пусть оно лучше упадёт. Забывая, что в C/C++ это UB.

> А ржавчики будут кодячить без усталости и лени! :-)))))

Как я говорил - вы ни фига не поняли. "Ржавчики" такие же люди, по этому язык исключает ситуации, когда эта возня понадобится. Внутри безопасного кода не может возникнуть null или висячий указатель.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

99. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от iZEN (ok) on 12-Мрт-18, 12:35 
> Внутри безопасного кода не может возникнуть null или висячий указатель.

Все объекты, используемые хоть раз в программе, что, сразу нужно инициализировать (создавать) и до отказа по ошибке OutOfMemoryError? В надёжной безопасной программе разве запрещено динамическое/"ленивое" создание объектов, когда ссылка на объект есть, но самого объекта нет - он будет создан и инициализирован в момент обращения к нему? Тогда готовьте разориться на оперативную память для инициализации всего и вся в момент старта программы.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

102. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Iaaa (ok) on 12-Мрт-18, 13:26 
Да забей ты. Поносятся годик второй с этой модной молодежной поделкой. Накопится достаточное количество реальных проектов, и все вернется на круги своя.

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

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

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

104. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Nexmean on 12-Мрт-18, 14:03 
> ссылка на объект уже есть а объекта еще нет

Вы сами то поняли, что сказали? Типа указатель у нас уже есть на память, но там ещё ничего нету, а появится магическим образом как только мы туда обратимся? Или это какой-то умный указатель? Так таких указателей можно и в русте наклепать. Или хотите чтобы у вас такие вещи автоматом работали? Ну тут в примитивных ситуация и джавка справится и gcc и rust, а в сложных только всякие Haskell и тому подобные.

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

106. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Andrey Mitrofanov on 12-Мрт-18, 14:22 
>> ссылка на объект уже есть а объекта еще нет
> Вы сами то поняли, что сказали?

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

Это ничего, что Вы чего-то не знаете.

Плохо, что Вы делаете из этого неправильные выводы.

Скушайте немного этих мягких https://www.microsoft.com/en-us/research/wp-content/uploads/... французских микрософт-рисиорчей, да выпейте жж водички.

Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

105. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Nexmean on 12-Мрт-18, 14:07 
Ну а ещё есть Option<T>, который от null отличается тем, что если в нем лежит НИЧЕГО, то и попробовать обратиться к T не получится.

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

26. "Для Linux и Redox представлена реализация Libc на языке Rust"  +7 +/
Сообщение от Crazy Alex (ok) on 09-Мрт-18, 13:29 
"Работа над проектом началась неделю назад и функциональность библиотеки пока сильно ограничена" - ну и смысл в таких новостях? Когда что-то хотя бы слегка живое будет - тогда и поговорим. И даже после этого - в реальном применении возникнет миллион нюансов, частных случаев и прочего, и только после возни с ними станет понятно, жизнеспособна идея или нет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 14:23 
> Работа над проектом началась неделю назад

Вопрос, дотянет ли оно хотя бы до четвёртой недели.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

29. "Для Linux и Redox представлена реализация Libc на языке Rust"  +5 +/
Сообщение от RobotsCantPoop on 09-Мрт-18, 14:41 
Первый релиз нового быстрого офиса, без глюков работающего с doc и docx:

int main()
{
    return 0;
}

Посоны, заходите коммитить, я создал!

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

30. "Для Linux и Redox представлена реализация Libc на языке Rust"  +3 +/
Сообщение от Anonymous Coward on 09-Мрт-18, 14:47 
exit(EXIT_SUCCESS);
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

36. "Для Linux и Redox представлена реализация Libc на языке Rust"  +7 +/
Сообщение от A.Stahl (ok) on 09-Мрт-18, 15:13 
Вот! Уже можно ещё одну новость писать про значительные улучшения, про сообщество с патчами и даже честно можно приложить ченджлог!
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

69. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от freehck email(ok) on 10-Мрт-18, 09:09 
Смысл новости в подтексте видимо, который такой: некоторые люди считают, что rust уже достаточно зрел для того, чтобы переписать на нём libc.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

38. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Аноним (??) on 09-Мрт-18, 15:30 
Пиарят Rust как могут. Только лучше бы толковых библиотке понаписали и примеров понаделали, а то быстрое знакомство с языком пока только рвотный рефлекс производит. А это сразу отворачивает всех.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 16:58 
С нетерпением жду когда питонисты подхватят знамя и напишут стандартную либу для сишников.
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

45. "Для Linux и Redox представлена реализация Libc на языке Rust"  +3 +/
Сообщение от Аноним84701 (ok) on 09-Мрт-18, 17:32 
> С нетерпением жду когда питонисты подхватят знамя и напишут стандартную либу для сишников.

Там "знамя", AFAIK, немного не о том.
Поэтому питонистам придется сначала написать свою ОСь на питоне и Pylibc под нее, а потому уже думать о портировании на прочие ОСи.

А вообще,  некоторым опеннетчикам не угодишь:
Использовали cишный  – "Фи! Не осилили даже стандартный ОСевой рантайм на своей ржавчине для своей игрушки написать!"
Начали писать на ржавчине – и опять все не так, "Бласфемия! Да как они смеют!".

Как будто следующим шагом будет принудительная установка и использование под страхом отлучения от интернета.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

46. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 17:54 
> Поэтому питонистам придется сначала написать свою ОСь на питоне и Pylibc под
> нее, а потому уже думать о портировании на прочие ОСи.

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

> Использовали cишный  – "Фи! Не осилили даже стандартный ОСевой рантайм на
> своей ржавчине для своей игрушки написать!"

Ну, хорошо, уговорил. В ненужно-ос появилась ненужно-либ. А чтобы это за игрушку не считали - наверное, авторам и фанатам неплохо бы своей операционкой пользоваться. Хотя-бы для себя. Для своих повседневных задач. Ну или нафиг еще операционка может быть нужна?

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

49. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Аноним84701 (ok) on 09-Мрт-18, 18:46 
> Ну или нафиг еще операционка может быть нужна?

Ну а нафиг на опеннте еще одно (не)нужное мнение о (не)нужности (не)нужного!?
"Just For Fun!"(c)

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

39. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Ivan_83 (ok) on 09-Мрт-18, 15:47 
Очередной пеар от раст боев.
У раста ещё меньше каких то полезных работающих проектов чем у го.

Кроме пеара в общем то у обоих новых языков ничего и нет, на фоне мира си и крестов.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

110. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Аноним (??) on 13-Мрт-18, 14:38 
>раст боев

Что, так и хочется сказать прямо, да? ;)

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

43. "Для Linux и Redox представлена реализация Libc на языке Rust"  –3 +/
Сообщение от анонимус (??) on 09-Мрт-18, 17:05 
Зачем тащить этот образчик, как не надо делать в новую ось?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

52. "Для Linux и Redox представлена реализация Libc на языке Rust"  –1 +/
Сообщение от Вареник on 09-Мрт-18, 20:45 
Избыток свободного времени и неумение найти ему лучшее применение.

Давайте перепишем окаменелости мамонта 100500 раз, но на этот раз с хрустом, а не на JS.

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

44. "Для Linux и Redox представлена реализация Libc на языке Rust"  +3 +/
Сообщение от Аноним (??) on 09-Мрт-18, 17:32 
> избавиться от свойственных языку Си усложнений при организации работы с памятью

и приобрести 5 новых типов указателей.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Ordu email(ok) on 09-Мрт-18, 19:57 
> Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями

Особенно при написании функции strlen, например. Или при реализации printf.
Кстати, любопытно как они собираются разруливать varargs, если rustc вечно настаивает на том, чтобы сохранять за собой возможность точно рассчитать на этапе компиляции размер стека, который требуется для программы.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

51. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Вареник on 09-Мрт-18, 20:43 
Про безопасность ранней Жавы говорил что-то схожее "безопасности" нынешнего сырого хруста в руках малолетних фанатиков :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

57. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от _ (??) on 09-Мрт-18, 21:50 
Вот! Просто таких старых как мы с тобой уже почти не осталось, другие забыли, а новые - и не знали никогда! :-)
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

56. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Нет ты on 09-Мрт-18, 21:47 
Безопасненько

#[no_mangle]
pub unsafe extern "C" fn strncat(s1: *mut c_char, s2: *const c_char, n: usize) -> *mut c_char {
    let mut idx = strlen(s1 as *const _) as isize;
    for i in 0..n as isize {
        if *s2.offset(i) == 0 {
            break;
        }

        *s1.offset(idx) = *s2.offset(i);
        idx += 1;
    }
    *s1.offset(idx) = 0;

    s1
}

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

59. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Аноним (??) on 09-Мрт-18, 22:28 
Так и запишем: go для безделушек типа сервисов, rust для системных безделушек. Хотя, если не загнутся, и те и те могут оказаться полезными.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

84. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Аноним (??) on 10-Мрт-18, 22:32 
> Так и запишем: go для безделушек типа сервисов, rust для системных безделушек.
> Хотя, если не загнутся, и те и те могут оказаться полезными.

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

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

90. "Для Linux и Redox представлена реализация Libc на языке Rust"  –2 +/
Сообщение от Аноним (??) on 11-Мрт-18, 09:59 
Заметьте, снова под нормальной свободной лицензией (MIT), а не вирусным несвободным недоразумением от ГНУ.

Скоро отовсюду его выкинут, уже к либку подбираются. МОЛОДЦЫ!!!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

92. "Для Linux и Redox представлена реализация Libc на языке Rust"  +2 +/
Сообщение от Nexmean on 11-Мрт-18, 11:37 
Кстати да, MIT лицензия может стать очень серьёзным конкурентным преимуществом данной реализации. Ибо, насколько я знаю, все реализации libc, которые хоть сколько нибудь живы нынче под прости господи копилефт лицензиями.
Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

109. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Аноним (??) on 13-Мрт-18, 14:34 
Не ново. Musl несколько лет уже есть, он под MIT.
Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

111. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от Аноним (??) on 13-Мрт-18, 14:46 
Чем бы дитя не тешилось...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

112. "Для Linux и Redox представлена реализация Libc на языке Rust"  +/
Сообщение от dq0s4y71 (ok) on 13-Мрт-18, 14:47 
> Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.

Интересно, а malloc (и вообще работу с динамической памятью) они в этой библиотеке каким образом реализовали?

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

114. "Для Linux и Redox представлена реализация Libc на языке Rust"  +1 +/
Сообщение от Аноним (??) on 13-Мрт-18, 15:33 
> Интересно, а malloc (и вообще работу с динамической памятью) они в этой
> библиотеке каким образом реализовали?

https://github.com/redox-os/relibc/blob/1b1ff5c750cac0db2324...


pub unsafe extern "C" fn malloc(size: size_t) -> *mut c_void {
        let align = 8;
        let ptr = ralloc::alloc(size + 16, align);


> Похоже, ребята придумали такую "безопасную версию" пилорамы - с циркулярной пилой без
> зубьев. А когда на ней нужно что-нибудь распилить, пилу нужно временно
> поменять на нормальную, с зубьями. Зато она теперь Безопасная, чо.

Похоже, опять пришла пора притянутых за уши аналогий?

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


Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема


  Закладки на сайте
  Проследить за страницей
Created 1996-2018 by Maxim Chirkov  
ДобавитьПоддержатьВебмастеруГИД  
Hosting by Ihor