The OpenNET Project / Index page

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



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

"Линус Торвальдс раскритиковал регистронезависимые файловые системы"  +/
Сообщение от opennews (??), 28-Апр-25, 19:46 
В ответ на публикацию исправления проблемы, связанной с поддержкой работы ФС Bcachefs в режиме без учёта регистра символов в именах каталогов, Линус Торвальдс заявил, что разработчики ФС видимо не способны учиться на своих ошибках, поскольку это далеко не первая проблема в коде обработки регистронезависимости...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=63149

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

Оглавление

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

1. Сообщение от Аноним (1), 28-Апр-25, 19:46   +20 +/
Он ещё не учёл, что в каждой новой версии стандарта Unicode появляются новые правила. Одна программа может поддерживать одну версию стандарта, а другая другую и их поведение в обработке одинаковых данных будет отличаться.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18, #27, #46, #166

2. Сообщение от Аноним (2), 28-Апр-25, 19:50   +13 +/
> Торвальдс сообщил, что времена FAT давно закончились

EFI system partition уже можно в ext4 ?!!

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #19, #43, #52, #53, #72, #119, #171, #176, #276, #365

3. Сообщение от Аноним (3), 28-Апр-25, 19:51   –23 +/
Все правильно сказал. Регистронезависимость -- это Приколюха™, которую нам подложили диды. Те же самые диды, которые решили, что было бы Прикольно™, если бы IP-адреса записывались не только как десятичные числа через точку, но и как всякие там 127.1, 0x7f.0.0.1 и еще какая-нибудь ересь.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #9, #10, #76

5. Сообщение от Аноним (5), 28-Апр-25, 19:54   +4 +/
Жиза, только сегодня пришлось иметь дело с renpy и файлы были в рандомном регистре повсюду. Часто с электроном то же самое.
Ответить | Правка | Наверх | Cообщить модератору

7. Сообщение от Анон321 (?), 28-Апр-25, 19:55   +34 +/
Молодому поколению похоже не объяснили, что ip-адрес это просто число. А запись числа может быть любой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #11, #12, #177

8. Сообщение от Аноним (8), 28-Апр-25, 19:55   +2 +/
Разрешаю!
Можешь реализовать, а мы посмотрим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #26, #322

9. Сообщение от Илья (??), 28-Апр-25, 19:57   –1 +/
> 0x7f.0.0.1

ужас. кошмар. Но я знаю одного человечка, который в HTTP статусах возвращал 0x404 и 0x200.

Он думал, что хакеры вот так по крутому числа пишут, наверное

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #95, #97

10. Сообщение от Аноним (1), 28-Апр-25, 19:57   +21 +/
Вас это удивит, но наберите в браузере http://3644916501/63149
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #20, #22, #25, #66, #99, #286

11. Сообщение от Аноним (11), 28-Апр-25, 19:58   –8 +/
Старшему поколению походу не объяснили, что поддерживать множество способов ввода числа нужно сразу везде: во всех приложениях с полем ввода IP-адреса, во всех библиотеках, парсящих IP-адрес из строки. В итоге разные приложения/библы поддерживают разную часть Прикольного™ RFC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #140

12. Сообщение от Илья (??), 28-Апр-25, 19:59   –5 +/
> А запись числа может быть любой.

А есть хотя бы одна причина использовать какие-то числа кроме ОБЫЧНЫХ ?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #21, #79, #84, #143, #220, #278, #289, #414

13. Сообщение от xsignal (ok), 28-Апр-25, 20:02   +2 +/
Пингвин прав - регистронезависимые имена файлов это сознательное упрощение для первых неискушённых пользователей персональных компьютеров времён MS-DOS с кодировкой ASCII, чтобы им было проще освоить диковинную чудо-технику. Но сейчас-то все уже прошаренные - называют файлы большими и маленькими буквами, некоторые даже с пробелами)) Зачем тащить этот анахронизм в сегодняшнее время? Тем более в юникоде понятие регистра действительно крайне расплывчатое...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #74, #156, #347

15. Сообщение от svsd_val (ok), 28-Апр-25, 20:06   –2 +/
Всё верно сказал!
Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от User (??), 28-Апр-25, 20:08   +/
Некоторые даже в национальных кодировках, прикинь! Но, как правило - не ъ. Третьего дня мне тут пара человек зачесывала кто за название книг транслитом, кто против имен возможности имена пользователя\пароли в кодировках, отличных от дефолтной протестовал, кто на Power-Shell ругался...
В общем, те-о-ре-ти-чес-ки да, но нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #217, #236

18. Сообщение от Аноним (18), 28-Апр-25, 20:08   –1 +/
> Он ещё не учёл, что в каждой новой версии стандарта Unicode появляются новые правила

Какие например?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #169

19. Сообщение от Я (??), 28-Апр-25, 20:08   +4 +/
вообще можно.. но стандарт требует от производителей ефи добавлять только минимальный набор драйверов среди которых нет ехт4, но он не запрещает его добавлять а значит можно иметь ефи систем партишн на любом разделе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #129

20. Сообщение от Аноним (20), 28-Апр-25, 20:08   +/
Однако
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

21. Сообщение от Страдивариус (?), 28-Апр-25, 20:22   +6 +/
Чуви явно не видел IP-адреса IPv6. Ничего, подрастёшь и узнаешь, а пока делай ДЗ и кушай кашку
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #405

22. Сообщение от Аноним (22), 28-Апр-25, 20:23   +/
молодец. Теперь бери этот айпишник - 3644916501 - и попробуй его вводить во все остальные проги: настройки прокси-сервера, нетворк-менеджер, какой-нибудь ip route add, cli докера, пинг, а еще вот сюда: https://www.wikihow.com/images/thumb/2/25/Find-Your-Subnet-M...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #45, #293

23. Сообщение от Аноним (23), 28-Апр-25, 20:23   +3 +/
сердечки в юникоде еще и размер меняют?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39, #296

25. Сообщение от Аноним Анонимович Анонимов (?), 28-Апр-25, 20:25   +/
Это что такое?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

26. Сообщение от Аноним (26), 28-Апр-25, 20:25   +1 +/
Кто сказал CoreBoot и CanoeBoot?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #55

27. Сообщение от Аноним (-), 28-Апр-25, 20:31   +5 +/
Стандарт Юникода нельзя сравнивать со Стандартами языков программирования. В Юникоде кодовые позиции символов не пересматриваются. Каждый следующий стандарт привязывает к определённой кодовой позиции какой-либо символ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #28

28. Сообщение от Аноним (-), 28-Апр-25, 20:33   –2 +/
... к незанятой кодовой позиции, какой-нибудь "новый" символ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

29. Сообщение от Аноним (29), 28-Апр-25, 20:35   –7 +/
Пивожор как-то забыл, что был ASCII одним регистром во времена, когда он ещё не умел списывать. И что filename должен быть именно что name, где Алекс, алекс и аЛеКс — это одно и то же, а смайлы должны запрещаться/меняться на всякие (0x444) и т.д.
Регистронезависимость в именах файлов — благо системного уровня, а не прикол от дедов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #54, #69

31. Сообщение от Аноним (33), 28-Апр-25, 20:44   –1 +/
Есть хоть одна техническая причина превращать одно имя файла в другое? Линус прав, имя файла - это просто набор байтов, и самый переносимый способ записывать имя - это любые байты, кроме '\0', '/' и ещё '\n', но во многих случаях даже он ничего не сломает. Если файловая система занимается подобной хренью, как превращение одних кодировок в другие или сменой регистра, то пусть будут добры занимать сразу ВСЕ возможные имена, если им делать нехрен.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #223

32. Сообщение от Уникум (?), 28-Апр-25, 20:44   +5 +/
Не вижу проблемы в создании стандарта с набором регистрозависимых символов, включающего только алфавиты существующих языков + что-то по иероглифам если там оно есть. Всё остальное не имеет регистра и не учитывается. Готов к решению следующей задачи
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #83

33. Сообщение от Аноним (33), 28-Апр-25, 20:45   +1 +/
Никто не виноват, что вас в шелле не научили эскейпить файлы и параметры в кавычки брать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

39. Сообщение от Аноним (-), 28-Апр-25, 20:57   +/
>сердечки в юникоде еще и размер меняют?

Не понял вопроса? Есть кодовая позиция, она может быть занята определённым символом, либо может быть незанятой, свободной. Если красному и чёрному сердцу отвели определённые кодовые позиции, то это разные символы. Если например, не вдаваясь в подробности просто, символ "сердце" привязяли к определённой кодовой позиции, и нет других привязок с графичеим русунком в форму сердца. То тогда все сердца разных форм и цветов будут считаться одним символом. Такова анатомия Юникода. Всё дело в привязке: "кодовая позиция = графический рисунок".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #49, #136, #137

43. Сообщение от НяшМяш (ok), 28-Апр-25, 21:04   –1 +/
В маке вроде hfs+? =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #51, #396

44. Сообщение от BrainFucker (ok), 28-Апр-25, 21:06   –3 +/
Нашёл о чём капитанить, старый брюзжун. Лучше бы набросил на тему неактуальности древовидных ФС с их директориями/папками, симлинками и прочим.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #415

45. Сообщение от Аноним (45), 28-Апр-25, 21:16   –2 +/
Поэтому и изобретают json, потому как думают, что всё должно быть читаемым. Им же не приходит на ум, что процессор видит только числа и никаких скобок и прочего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #175

46. Сообщение от Карлос Сношайтилис (ok), 28-Апр-25, 21:16   +6 +/
Он-то как раз и учёл. И прямо об этом говорит.
И появляются не "правила", а новые символы и новые, дополнительные интерпретации. Старое не ломается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

48. Сообщение от trolleybus (?), 28-Апр-25, 21:18   +2 +/
Тут не с регистронезависимостью проблема, а с тем, что в именах файлов разрешена всякая дичь вроде вот этих юникодных сердечек.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #58, #61, #351, #376

49. Сообщение от Аноним (45), 28-Апр-25, 21:19   +/
Сердечки в имени файла. Это мы заслужили. За такое надо было бить по рукам с самого начала, а теперь все эти dei расплодились.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #80, #148, #239

51. Сообщение от Минона (ok), 28-Апр-25, 21:24   +1 +/
В маке APFS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #302

52. Сообщение от sergey (??), 28-Апр-25, 21:26   +/
В смысле? Вы в курсе что если в новой системе форматировать диск в ext4 в его в старой системе (где то же есть ext4) не сможете даже примонтировать !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #121, #184

53. Сообщение от Ан Оним (?), 28-Апр-25, 21:27   +2 +/
ESP - это ошибка
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #180

54. Сообщение от Карлос Сношайтилис (ok), 28-Апр-25, 21:28   +6 +/
> был ASCII одним регистром во времена

Никогда не был. Символы 'A' и 'a' имеют разные коды в ASCII

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #264

55. Сообщение от Аноним (55), 28-Апр-25, 21:29   +3 +/
KogoeBoot?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #128

57. Сообщение от Аноним (109), 28-Апр-25, 21:30   +2 +/
> в режиме без учёта регистра

А теперь поиграйтесь в регистре где символы L I i l выглядят одинаково.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #60

58. Сообщение от тоже Анонимemail (ok), 28-Апр-25, 21:31   +5 +/
Ну, иди расскажи японцам, что они должны файлы латиницей называть.
Проблема вообще не в символах, а всего лишь в синдроме утенка вскормленных Виндой.
Они считают правильной всю ту дичь, которую Микрософт накосорезил в своих системах в 1980-х - и продолжает бережно тащить ее в 2020-е.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #71, #75, #100, #227, #259, #330

59. Сообщение от Аноним (60), 28-Апр-25, 21:34   –4 +/
Я всегда говорил что Линус наш слоняра. Все правильно и по полочкам разложил.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #65

60. Сообщение от Аноним (60), 28-Апр-25, 21:35   +/
Если я хочу тебя взломать  или обмануть это мне только плюс. Поэтому я буду продавливать регистронезависимость всеми силами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #63, #67

61. Сообщение от Chel (?), 28-Апр-25, 21:37   +/
Напиши список разрешенных символов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #64, #144

63. Сообщение от Аноним (109), 28-Апр-25, 21:41   +/
Да не, иногда в шрифтах L выглядит как i, 0 как o, я про это.
Меня нечего взламывать, я не криптовалютчик.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #82, #370

64. Сообщение от trolleybus (?), 28-Апр-25, 21:46   –2 +/
Этот список уже до меня давно написали. ASCII называется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #70

65. Сообщение от Аноним (109), 28-Апр-25, 21:47    Скрыто ботом-модератором+4 +/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

66. Сообщение от Аноним (66), 28-Апр-25, 21:48   +2 +/
Меня это ОЧЕНЬ удивило, спасибо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

67. Сообщение от trolleybus (?), 28-Апр-25, 21:49   +1 +/
> регистронезависимость

Так это как раз про регистрозависимость. В каком-нибудь досе или винде 3.1 по умолчанию все имена файлов заглавными буквами показываются, и сразу понятно, где L, а где I.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #81

69. Сообщение от YetAnotherOnanym (ok), 28-Апр-25, 21:53   +4 +/
Регистронезависимость в именах файлов - отрава и мина замедленного действия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #242

70. Сообщение от YetAnotherOnanym (ok), 28-Апр-25, 21:56   +/
Ну, ок, конвертнём в base64 и будем в таком виде хранить на диске, а в файлменеджере будем показывать исходную форму с сердечками, иероглифами и арабской вязью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

71. Сообщение от _hide_ (ok), 28-Апр-25, 22:00   +1 +/
Ну регистронезависимость важна при поиске. При обращении к файлу регистр однозначно должен соблюдаться, в противном случае имя файла нельзя представить в виде набора конкретных байт и тут все абстракции поехали... Как велосипед на квадратных колёсах!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #113

72. Сообщение от Аноним (72), 28-Апр-25, 22:01   +1 +/
> EFI system partition уже можно в ext4 ?!!

Можно, и не только в ext4: https://efi.akeo.ie/downloads/efifs-1.11/x64/

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #231

74. Сообщение от Zenitur (ok), 28-Апр-25, 22:02   +/
Но ведь и в ext4 недавно добавили nocase: https://www.opennet.me/opennews/art.shtml?num=50581
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #93

75. Сообщение от Zenitur (ok), 28-Апр-25, 22:05   +2 +/
Против символов национальных алфавитов никто не против. А вот цветные смайлики в именах файлов... Зачем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #88, #109, #266

76. Сообщение от Аноним (-), 28-Апр-25, 22:06   +/
Ну вот маску подсети можно было бы как-то проще делать или наоборот - более интересно. Хорошо хоть короткую преамбулу придумали и на этом спасибо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #216

77. Сообщение от YetAnotherOnanym (ok), 28-Апр-25, 22:07   –2 +/
Поздно рассуждать о боржоми, когда почки накрылись. Само появление не-ascii символов в именах файлов открыло ящик пандоры. ИЧСХ, если появится менеджер паролей i❤mypasswords или криптокошелёк i❤cryptocoins - найдутся лопухи, которые будут ими пользоваться, и их потом поимеет злой хакирь, который выпустит, соответственно, менеджер паролей i❤️mypasswords или криптокошелёк i❤️cryptocoins со зловредами внутри, в том же каталоге приложений.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #120

78. Сообщение от Zenitur (ok), 28-Апр-25, 22:08   –2 +/
> времена FAT давно закончились

Тут я бы поспорил. Даже на больших флешках, таких как 128 Гб, FAT32 прекрасно себя чувствует. По размеру кластера они вроде как с exFAT одинаковы. Единственный минус - нельзя создавать файлы больше 4 Гб.

FAT32 позволяет вставить флешку в телевизор, магнитолу, приставку, смартфон, и не думать "а поддерживается ли там exFAT или нет?".

По поводу юникода и FAT32. Поддерживается. Файлы со спецсимволами создаются. А во поводу регистров (а тем более регистров спецсимволов), ну, под Linux FAT32 case sensitive. А под виндой nocase. Но там и NTFS - nocase.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #85, #309

79. Сообщение от ProfessorNavigator (ok), 28-Апр-25, 22:10   +2 +/
> А есть хотя бы одна причина использовать какие-то числа кроме ОБЫЧНЫХ ?

Что такое "обычные" числа? Беззнаковые целые длиной 8, 16, 32, 64 бита? Знаковые той же длины? Т.н. числа с плавающей точкой? Это раз.

Два - вон там рядом новость про qbittorrent. Торрентами пользуетесь? Наверняка. А в их спецификации есть такая штука, как DHT. Где идентификатор каждого узла - число в 20 байт длинной. Более того, для работы DHT над такими числами ещё и разные операции совершать нужно - XOR, сравнение. Шифрование - тоже внезапно сплошь и рядом работа с "длинной" арифметикой. А без шифрования вы бы даже сюда не попали - сайт то скорее всего по протоколу https загружен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #172

80. Сообщение от Аноним (-), 28-Апр-25, 22:11   –1 +/
> За такое надо было бить по рукам с самого начала

А за умляуты в имени файла тоже? Это же такая наглость желать писать слово правильно!
А за иероглифы тоже?

Слава богу таких даунито как ты никто не слушал. И позволили писать то, что они хотят.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #117, #222

81. Сообщение от Аноним (93), 28-Апр-25, 22:11   +/
Не было такого в досе и 3.1. Прописными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #308

82. Сообщение от YetAnotherOnanym (ok), 28-Апр-25, 22:12   +2 +/
Диды придумали нолик зачёркивать. И всё было хорошо, однозначно и недвусмысленно, пока не пришёл юникод со скандинавским Ø.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #118, #360

83. Сообщение от Аноним (83), 28-Апр-25, 22:12   +4 +/
Ты предложил простое и неправильное решение. С турецким языком что делать будем, например? Там с английским регистры их версий I не совпадают: I → ı, İ → i.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #116

84. Сообщение от Аноним (-), 28-Апр-25, 22:13   +/
16тиричная система не так уж и плоха для адресов от 00 до ff в каждом из 4 сегментов адреса. 7F.0.0.1 или C0.A8.0.1 выглядит ничуть не хуже десятичной системы, даже как-то лаконичнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #131, #160, #303

85. Сообщение от Аноним (85), 28-Апр-25, 22:14   +2 +/
Разве речь о том, чтобы выпилять FAT32 из линукса?

Речь о том, чтобы в новые ФС не тянуть старые неактуальные привычки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #89, #94

86. Сообщение от Аноним (-), 28-Апр-25, 22:15   +/
Торвальдс однозначно не прав.
Все эти свистелки и перделки разбаловали юзеров!

Нужно делать как в RT-11.
6+3 длинна имени файла, и фиксированный набор "A—Z, 0—9, $, ., %"
Этого хватит всем!

А то взяли моду придумывать длинные названия, да еще и какие-то сердечки туда пихать!!11

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #105, #313, #393

88. Сообщение от Аноним (-), 28-Апр-25, 22:16   +/
> Против символов национальных алфавитов никто не против.

В чем разница? Написать 赤いハート или поставить ❤️?

> А вот цветные смайлики в именах файлов... Зачем?

Не зачем, а почему бы и нет. И то, и другое просто код юникода.
В данном случае проблема это "регистронезависимые файловые системы". Которые просто пережиток старых времен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #111, #186

89. Сообщение от Zenitur (ok), 28-Апр-25, 22:16   +2 +/
> Разве речь о том, чтобы выпилять FAT32 из линукса?
> Речь о том, чтобы в новые ФС не тянуть старые неактуальные привычки.

Ну не знаю, мне лично с nocase удобнее. Всяко лучше, чем иметь в одной папке файлы вида:

привет.txt
Привет.txt
ПрИвЕт.txt
привет.txT

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #107, #193

93. Сообщение от Аноним (93), 28-Апр-25, 22:23   +/
Опционально. Очевидно - для узких нужд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #104

94. Сообщение от тоже Анонимemail (ok), 28-Апр-25, 22:24   +/
> старые неактуальные привычки

Это называется "обеспечивать совместимость, столь ценимую нашими корпоративными клиентами". Например, так:


Invalid file or folder names
Applies to: OneDrive for Business

These names aren't allowed for files or folders: .lock, CON, PRN, AUX, NUL, COM0 - COM9, LPT0 - LPT9, _vti_, desktop.ini, any filename starting with ~$.

Notes:
    _vti_ can't be used anywhere in a file name.
    forms can't be used when the folder or file is at the root level of a library.
    ゛​​​​​​​and ဧ can't be used as the first character of a folder.



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

95. Сообщение от Аноним (-), 28-Апр-25, 22:25   +/
Не мог он возвращать 0х404. На что вы намекаете? Говорите прямо
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #161

97. Сообщение от Аноним (-), 28-Апр-25, 22:28   +/
> 0х200

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

Мдя..

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

99. Сообщение от Аноним (-), 28-Апр-25, 22:34   +2 +/
Меня удивляет что это кого-то удивляет. И много ли тут людей меньше 20?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #214

100. Сообщение от RHEL fan (?), 28-Апр-25, 22:35   +3 +/
Ничего они, поди, email адреса то латиницей пишут, не обламываются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #135

104. Сообщение от Аноним (104), 28-Апр-25, 22:40   +/
> Опционально. Очевидно - для узких нужд.

А кстати, для каких? Всегда было любопытно

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #127, #155, #251, #317

105. Сообщение от Аноним (109), 28-Апр-25, 22:40   –1 +/
> Нужно делать как в RT-11.
> 6+3 длинна имени файла, и фиксированный набор "A—Z, 0—9, $, ., %"

Ну вообще чем прощще тем лучше, тем это более надежнее, правда длинна имени файла коротка.
Насамом деле как в Windows, нормально вполне.
Или это такое развлечение, играться с именами файлов папок из таблицы символов, сомнительное развлечение.
Все эти регистры, Temp temp.

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

107. Сообщение от Аноним (109), 28-Апр-25, 22:42   –1 +/
> с nocase удобнее. Всяко лучше, чем иметь в одной папке файлы вида:
> привет.txt
> Привет.txt
> ПрИвЕт.txt
> привет.txT

Соглашусь,
Temp
temp

Круто., а теперь разберись какая из них, Temp, temp.
Это как пример.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #123

108. Сообщение от Аноним (-), 28-Апр-25, 22:42   –1 +/
С точки зрения пользователя все же регистронезависимые имена удобны. И если проблема в похожих символах UTF-8, которые нельзя порой в нужный регистр привести, то может проблема в UTF-8?
Ответить | Правка | Наверх | Cообщить модератору

109. Сообщение от Аноним (109), 28-Апр-25, 22:43   +/
> А вот цветные смайлики в именах файлов... Зачем?

Просто красиво,

Только найди потом файл с таким названием.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #112, #241

111. Сообщение от Аноним (111), 28-Апр-25, 22:48   +1 +/
>> Против символов национальных алфавитов никто не против.
> В чем разница? Написать 赤いハート или поставить ❤️?

Ну зачем так далеко ходить:
ͦpͤnnͤͭ - удачи любителям "независимости" подобрать тот самый, единственно-верный "регистронезависимый" вариант. Я уж не говорю о всяких скучных öäÜóß ... и о том, как ЭТО более-менее эффективно можно парсить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #122

112. Сообщение от Аноним (104), 28-Апр-25, 22:49   +/
>> А вот цветные смайлики в именах файлов... Зачем?
> Просто красиво,
> Только найди потом файл с таким названием.

У вас в find юникод сломали?


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

113. Сообщение от oficsu (ok), 28-Апр-25, 22:50   +6 +/
Для обеспечения регистронезависимого поиска по файловой системе вовсе не требуется поддержка со стороны файловой системы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

114. Сообщение от Аноним (-), 28-Апр-25, 22:50   –1 +/
Какие собственно проблемы хранить тогда локаль в файловой системе? Это от силы один байт. Да и при наличии локали отпадает необходимость в utf-8 или решает проблемы какими символами имя файла ограничить в utf-8. Главное графически отобразить локаль и будет сразу видно где турецкая l, а где английская l. Или чего там ещё. Ну а список эмодзи можно и ограничить, тогда и не будет проблем. У сердечек нет верхнего и нижнего регистра, это вообще картинка которая записана как символ в utf-8. Такие картинки порой решают некоторые проблемы программистов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #133

116. Сообщение от Аноним (-), 28-Апр-25, 22:53   +1 +/
> просто бесятся от того, что им приходилось пыриться в детстве в консольку.

Вот не надо тут. Мне в детстве приходилось пыриться в интерфес, сделанный из вот такой cpaни


╔════════════════════╗
║░░░░░░░░░░░░░░░░░░░░║
║░░░░░░░░OPEN░░░░░░░░║
║░░░░░░░░░░░░░░░░░░░░║
╚════════════════════╝

Но я совсем не против использования юникода в именах файлов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #240

117. Сообщение от Аноним (45), 28-Апр-25, 22:54   +/
Сперва сердечки разных цветов, потом буквы разных цветов. Это же круто, мы же всё можем. И причем тут национальные алфавиты? Там есть сердечки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #130, #383

118. Сообщение от Аноним (104), 28-Апр-25, 22:56   +/
> пока не пришёл юникод со скандинавским Ø.

Про ISO8859 ты, понятное дело, не в курсе.

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

119. Сообщение от ананим.orig (?), 28-Апр-25, 22:56   +1 +/
Ну да, времена FAT может и закончились, а вот мс до сих пор жив - поэтому секуре в бут вам всем, пока эту нежить не закопаете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

120. Сообщение от Аноним (104), 28-Апр-25, 23:00   +/
> Поздно рассуждать о боржоми, когда почки накрылись. Само появление не-ascii символов в
> именах файлов открыло ящик пандоры.

Как открыло, так и закроет. Немного боли и придет стандартизация.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #263

121. Сообщение от Аноним (121), 28-Апр-25, 23:00   +/
для переноса данных используется ext3, а для починки новой системы не используйте древний rescue. а спасти данные можно - читать то можно, только писать нельзя...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #124

122. Сообщение от Аноним (-), 28-Апр-25, 23:03   +/
> удачи любителям "независимости" подобрать тот самый,
> единственно-верный "регистронезависимый" вариант.

А зачем тебе вообще "регистронезависимый" вариант? Чтобы со всяким старьем было совместимо?
Сейчас даже NTFS поддерживает case-sensitive.

> Я уж не говорю о всяких скучных öäÜóß

Так как раз из-за того, что ß просто так в upper-case не конвертнешь, и нужно использовать case-insensitive!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #183

123. Сообщение от Аноним (104), 28-Апр-25, 23:04   +1 +/
> Круто., а теперь разберись какая из них, Temp, temp.
> Это как пример.

Три буквы: FHS.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #142, #147

124. Сообщение от Аноним (124), 28-Апр-25, 23:04   +/
ему не надо чинить. Там на старой системе отказ монтировать из-за того, что диск отформатирован с поддержкой фич, о которых старое ядро внезапно не знает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #218

127. Сообщение от Rollo99email (ok), 28-Апр-25, 23:32   +1 +/
Для совместимости с уже существующими решениями.

Например, при монтировании сетевой виндовой шары как cifs, регистр не учитывается.
Сервис, который с ней работает, ищет файлы по имени, а расширения перебирает по типам всегда в нижнем регистре.
Потребовалось сделать зеркало сервиса вместе с данными.

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #134

128. Сообщение от Аноним (128), 28-Апр-25, 23:32   +2 +/
Das U-Boot
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #154, #281

129. Сообщение от Аноним (128), 28-Апр-25, 23:34   +/
А исполняемые файлы EFI в формате ELF можно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

130. Сообщение от Аноним (104), 28-Апр-25, 23:35   +4 +/
Бессердечные алфавиты!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

131. Сообщение от Анониссимус (?), 28-Апр-25, 23:44   –1 +/
Суть не в том, хуже или лучше шестнадцатиричная запись десятичной. А в том, что вариант должен быть один, потому что это стандарт. Нет ни единой причины использовать много вариантов там, где можно использовать один. Было бы сэкономлено много человеколет, если бы стандартодатели выбрали бы один вариант для записи ip-адреса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #224

132. Сообщение от Аноним (133), 29-Апр-25, 00:01   +/
Торвальдс абсолютно прав. И правильное решение - прямо в винде включить регистрозависимые пути в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive=dword:00000000

Для тех каталогов, где прям супер-нужно регистронезависмость можно её включить через fsutil.exe file setCaseSensitiveInfo <path> enable/disable

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #157, #342

133. Сообщение от Аноним (133), 29-Апр-25, 00:02   +/
Такая, что это не очень совместимо с ФС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #221

134. Сообщение от Аноним (104), 29-Апр-25, 00:11   +/
Тут скорее имело бы смысл сделать запрос на доработку поиска (игнорировать регистр расширений).

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

На самбе, емнип, все эти штуки с регистром и автоконвертацией имён решались настройками сервера.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

135. Сообщение от тоже Анонимemail (ok), 29-Апр-25, 00:26   +/
> Ничего они, поди, email адреса то латиницей пишут, не обламываются.

Боюсь, обламываются, но не они - 二ノ宮@黒川.日本, например.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

136. Сообщение от Аноним (23), 29-Апр-25, 00:35   +1 +/
> Не понял вопроса?

ну вот у "а" и "А" одна и таже буква, имеют разные коды, и мы говорим что "А" это буква "а" большого размера (верхнего регистра). Ну вот с буквами понятно, а понятие регистра разве у сердечек есть? "Красное сердечко" никоим образом не является "регистром" "черного сердечка", это два разных символа.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #153, #335

137. Сообщение от Аноним (23), 29-Апр-25, 00:38   +/
> Такова анатомия Юникода. Всё дело в привязке: "кодовая позиция = графический рисунок".

а что есть регистр? это "кодовая позиция('a') ~ кодовая позиция('A')"

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

140. Сообщение от Аноним (140), 29-Апр-25, 00:50   +7 +/
А по какой причине предъява людям, придумавшим ИП, а не писателям программ втч себе?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #404

142. Сообщение от Аноним (142), 29-Апр-25, 00:51   +/
Никому не нужное нагромождение костылей, которого сам стандартизатор не придерживается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

143. Сообщение от Аноним (140), 29-Апр-25, 00:51   +/
а обычные у вас это какие числа?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #162

144. Сообщение от Аноним (109), 29-Апр-25, 00:52   –2 +/
Товальдс такой жест придумал нвидии.
Ну это которым потом он, пазязя, напишите драйверы.
А чтой то не пишут драйверы для Нвидиа.
Молодец ну.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

146. Сообщение от Аноним (146), 29-Апр-25, 01:05   +2 +/
А весь секрет в том, что юникод - это не кодировка, юникод - это бинарный формат для хранения текстовой информации, наравне с odt, openxml и Microsoft doc/docx. Именно поэтому там есть "символы" типа "обратить весь последующий текст задом нарерёд" и подобные, о которых никто не в курсе. Стоит понять эту простую истину, и куча вопросов к юникоду, используемому в качестве кодировки, сразу отпадает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #188, #206, #256

147. Сообщение от Аноним (109), 29-Апр-25, 01:14   +/
> Три буквы: FHS.

FHS, или фолликулостимулирующий гормон , — это гормон, вырабатываемый гипофизом как у мужчин, так и у женщин.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

148. Сообщение от Имя (?), 29-Апр-25, 01:41   +/
С чего бы анониму решать это? Хочу и использую, вот, держи 🤡
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

149. Сообщение от Аноним (355), 29-Апр-25, 01:48   +/
В винде ж как-то сделали.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #150, #179, #197

150. Сообщение от Аноним (150), 29-Апр-25, 03:41   –1 +/
Более того, там по ходу дискуссии дальше объясняют, что в винде NTFS как раз имеет правильное решение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #213

153. Сообщение от Аноним (153), 29-Апр-25, 04:24   +1 +/
Строго говоря Юникод не знает таких понятий как "верхний регистр", "нижний регистр". Есть кодовая позиция, и есть прявязанный к конкретно данному коду, символ. И всё! Термины: "регистр", "глиф символа", "кегль", "шрифт" относятся к типографике, а не Юникоду.
Юникод оперирует такими понятиями, как направления письма (левое, правое), можно ли один символ комбинировать с другим символом (диакритика), тип разрыва строки.

Кириллическое А = U+0410 - а это его кодовая позиция.
Кириллическое а - U+0430
Латинская A - U+0041
Латинская a - U+0061

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #192, #195, #238, #255

154. Сообщение от Was (??), 29-Апр-25, 04:37   +6 +/
U96: Das Boot
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #163

155. Сообщение от Аноним (155), 29-Апр-25, 05:36   +/
в комплект к вайну. когда пытаешься виндовое что-то копировать, типа патча поверх, то может оказаться всё в разных регистрах
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

156. Сообщение от Anonymously (-), 29-Апр-25, 05:48   +/
Маки тоже по дефолту apfs в case insensitive форматирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

157. Сообщение от Anonymously (-), 29-Апр-25, 05:52   +/
Ага, а потом сидеть гадать почему софтина не работает и пополнять список исключений
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #274

160. Сообщение от Илья (??), 29-Апр-25, 06:09   –3 +/
> выглядит ничуть не хуже десятичной системы, даже как-то лаконичнее.

Речь про сопровождение двух взаимоисключающих форматов записи.

Есть куча кода, для которого ip адрес это четыре байтовых числа через точку.

Твоё удобство и лаконичность я поддерживать не собираюсь


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #211, #282

161. Сообщение от Илья (??), 29-Апр-25, 06:13   +/
> Не мог он возвращать 0х404. На что вы намекаете? Говорите прямо

https://paste.pics/800754f3080456c9627bfe0ef0180452

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #173

162. Сообщение от Илья (??), 29-Апр-25, 06:18   –1 +/
> у вас

Зайди в магазин, купи 0xFA3 гвоздей

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #205, #212, #284

163. Сообщение от Аноним (163), 29-Апр-25, 06:26   +1 +/
>Maximum velocity
>Das boot
>System activated
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154

165. Сообщение от Аноним (-), 29-Апр-25, 06:34    Скрыто ботом-модератором–1 +/
Ответить | Правка | Наверх | Cообщить модератору

166. Сообщение от Аноним (-), 29-Апр-25, 06:37   +/
> Он ещё не учёл, что в каждой новой версии стандарта Unicode появляются
> новые правила. Одна программа может поддерживать одну версию стандарта, а другая
> другую и их поведение в обработке одинаковых данных будет отличаться.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #168, #237

168. Сообщение от Аноним (168), 29-Апр-25, 06:42   +1 +/
Больше всего мне нравятся толкователи слов  учителя. Но обычно толкованием занимаются после смерти, а тут ещё при жизни. Повезло ему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #170

169. Сообщение от Аноним (-), 29-Апр-25, 06:44   +3 +/
>> Он ещё не учёл, что в каждой новой версии стандарта Unicode появляются новые правила
> Какие например?

Черт знает насчет стандарта - а например андроида дико колбасит при попытке засэйвить имена файлов с цветными смайликами.

При том иногда оно умудряется - засэйвить. Но тогда - какая-нибудь программа типа индексатора или файлменеджера начинает выдаваьт совершенно левые сообщения при попытках что-то делать с этим файлом. И наверняка в софте есть более 9000 вулнов которые можно на этой почве проэксплуатировать.

Когда видение ОС/ФС и программы расходятся это целый класс багов, desync. Типа атак на HTTP хидеры когда разный парсинг там и тут юзается для чего-то полезного атакующему. Вот тут у вас deny не сработал и файло - умыкнули, а вот тут - файло удалось переписать леваком. А вот тут - вообще удалось ваши системы заклинить. Это мощный - и забавный - класс багов. Где очень сложно понять с какой стороны подстав вообще ждать. Торвальдс набрал достаточно опыта чтобы тоже это усвоить. Чем он и крут.

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

170. Сообщение от Аноним (-), 29-Апр-25, 06:50   +1 +/
> Больше всего мне нравятся толкователи слов  учителя. Но обычно толкованием занимаются
> после смерти, а тут ещё при жизни. Повезло ему.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #400

171. Сообщение от Аноним (-), 29-Апр-25, 06:52   +/
>> Торвальдс сообщил, что времена FAT давно закончились
> EFI system partition уже можно в ext4 ?!!

Теоретически там хоть btrfs можно. Практически - зависит от того какие драйвера ФС в фирмвари были.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

172. Сообщение от Аноним (172), 29-Апр-25, 07:08   +/
> узла - число в 20 байт длинной. Более того, для работы
> DHT над такими числами ещё и разные операции совершать нужно -
> XOR, сравнение. Шифрование - тоже внезапно сплошь и рядом работа с
> "длинной" арифметикой. А без шифрования вы бы даже сюда не попали
> - сайт то скорее всего по протоколу https загружен.

Более того - когда вы будете делать операции над числом 20 байтов размером - вы заодно невольно озаботитесь и endianess :) ибо есть минимум 2 способа записать такое число в память. Начиная с старшего байта, или с младшего.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #189, #243

173. Сообщение от Аноним (172), 29-Апр-25, 07:10   +/
>> Не мог он возвращать 0х404. На что вы намекаете? Говорите прямо
> https://paste.pics/800754f3080456c9627bfe0ef0180452

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

175. Сообщение от Аноним (-), 29-Апр-25, 07:16   +/
> Поэтому и изобретают json, потому как думают, что всё должно быть читаемым.
> Им же не приходит на ум, что процессор видит только числа
> и никаких скобок и прочего.

И его тоже полностью в полном виде - как generic - корректно от и до не парсит почти никто из существуюшего софта :). А реакция на "нежданчики" у софта бывает самой разной. Экспериментируйте - и вы найдете много вещей которых эти, которым не хочется напрягаться, забыли предусмотреть. Это позволит вам извлечь море лулзов.

Ну вот например я какого-то бота подвесил насмерть. Он просто не ожидал мой формат выхлопа и кажется очень увлекся парсингом. Посмотрим как такой оборот его владельцу :)

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

176. Сообщение от ryoken (ok), 29-Апр-25, 07:21   +1 +/
Воткните нужный драйвер в фирмварь и вперед. Вантуз правда будет в некотором удивлении и не сможет обновлять загрузчик. Но это может и хорошо :).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #232

177. Сообщение от ryoken (ok), 29-Апр-25, 07:23   +1 +/
Попробуйте попинговать адре типа 192.168.0.10 и 192.168.0.010. Меня результат удивил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #219, #226

178. Сообщение от Ося Бендер (?), 29-Апр-25, 07:25   –1 +/
Проблема не стоит выеденного яйца. Микрософт скоро закопают окна в пользу Марины и регистронезависимость ни кому будет не нужна.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #196, #230

179. Сообщение от Аноним (128), 29-Апр-25, 07:36   +/
Да наверняка сделали только для широкоизвестных алфавитов. А остальное, как придётся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #203, #269, #279, #332

180. Сообщение от Минона (ok), 29-Апр-25, 07:37   +1 +/
Точно!
Надо UKI сразу в ПЗУ шить. 😏
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #194

183. Сообщение от ryoken (ok), 29-Апр-25, 07:51   +1 +/
>>Сейчас даже NTFS поддерживает case-sensitive.

Да как бы не с W2K... Только в реестре отключено по дефолту и софту может чеку сорвать от таких фокусов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

184. Сообщение от Аноним (184), 29-Апр-25, 07:51   +1 +/
Монтируйте в ext2.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

186. Сообщение от Аноним (128), 29-Апр-25, 08:05   –1 +/
>В чем разница? Написать 赤いハート или поставить ❤️?

В количестве и комбинациях байт. Ели это имена файлов, то это два разных файла.

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

188. Сообщение от Namehh (?), 29-Апр-25, 08:21   +/
> docx

С каких пор он бинарный?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #275

189. Сообщение от Аноним. (?), 29-Апр-25, 08:23   +/
> Более того - когда вы будете делать операции над числом 20 байтов размером - вы заодно невольно озаботитесь и endianess :) ибо есть минимум 2 способа записать такое число в память.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #202, #250

192. Сообщение от Аноним (192), 29-Апр-25, 08:45   –1 +/
Прям какой-то антипатерн "dont repeat your self" получается...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

193. Сообщение от Аноним (194), 29-Апр-25, 08:46   +/
> Ну не знаю, мне лично с nocase удобнее. Всяко лучше, чем иметь
> в одной папке файлы вида:
> привет.txt
> Привет.txt
> ПрИвЕт.txt
> привет.txT

Гнилой виндузоид - палится сразу. Вон там для таких любезно штуки три CVE на основе такого упрощения. Представляешь, в уникоде топик кто кому upper case - весьма сложная штука. И это порождает неоднозначный парсинг.

Вот так вот тебе кто-то зальет ПрИвЕт.txt - а он и перезапишет привет.txt без спроса - хотя софт был уверен что все окей, файло же разное! При том понятие одинаковости и разности начинает еще и зависеть от программы - и попробуй вообще угадай где на тебя ВНЕЗАПНО упадет такой рояль.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #271

194. Сообщение от Аноним (194), 29-Апр-25, 08:49   +/
> Точно!
> Надо UKI сразу в ПЗУ шить. 😏

Рассматривая мини-линуз-как-бутлоадер в SPI флешке - да ты телепат почти?!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180

195. Сообщение от Аноним (192), 29-Апр-25, 08:49   +/
Это про
U+0410 и U+0041
U+0430 и U+0061
Если что
Сами-то символы одинаковые
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #273

196. Сообщение от Аноним (60), 29-Апр-25, 08:51   +/
Маринка кде закопали она теперь Азер Линукс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #201

197. Сообщение от Аноним (60), 29-Апр-25, 08:53   +/
В виде Легаси и совместимость. Которую надо тащить десятилетиями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #280

201. Сообщение от Ося Бендер (?), 29-Апр-25, 09:04   +/
Да без разницы, логика ведет к тому, что окна рано или поздно будут закопаны вместе со всем своим барахлом, в т.ч и с регистронезависимостью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196 Ответы: #207, #215

202. Сообщение от Аноним (-), 29-Апр-25, 09:05   +/
> Совершенно не важно, как число лежит в памяти.

Вообще-то важно. Ибо мы храним это число грубо говоря, как uint8_t whatever[20]. И вот тут возникает вопрос: whatever[0] это MSB или LSB этого числа? Сия договоренность также может влиять на транспортный формат. Если мы выстреливаем 20 байтов в провол - который из них будет первым в проводе? И что он представляет? Это важно для имплементера альтернативной реализации, который будет сам имплементить совместимое решение по спекам, а не "возьмите нашу волшебную фигню".

Это же будет колыхать и при чтении допустим файла в память. Потому что запись 20 байтов в файл - это запись 20 байтов в файл. Само по себе ничего не говорит как эти байты трактовать.

> Результат a+b не должен зависеть от расположения байт,

Вообще-то он таки будет зависеть от него при операции с 20-байтовым (160-битным) числом ибо делая математику "этажеркой" надо заморочиться в какую сторону carry делать.

Если что я писал сравнимую "широкую" математику. Ну напиши допустим сравнение A vs B на тему ">" или "<" не учитывая где MSB а где LSB в представлении something[20]. Это как бы влияет на то какой индекс надо первым чекать.

> это гарантирует язык программироавания (например, Си).

Покажи мне в си работу с целыми integer, размером 2^160. Вон тому типу это надо - для DHT, там адресация 160 битов. Ну и кроме всего прочего с этими числами делается математика. Конечно есть либы для big int, но тот вопрос полностью не отвалится и там - и они могут быть и не оптимальны для частного случая 1 конкретной математики фиксированной - но большой - ширины.

А еще бывает математика с КАСТОМНЫМИ правилами. Что такое "operator +" и "operator -" или например "operator > " в той или иной математике может здорово варьироваться. Если сомневаетесь посмотрите на поля галуа допустим. А круто когда "operator +" определен так же как "operator -" и результат операций - одинаковый? :)

> endianess появляется, когда вы хотите отправить это число на другое устройчтво.

У вон того кадра это DHT, там это by default. Но вообще-то оно появляется и без отправки. Скажем реализуй "operator >" без знания где у тебя MSB и LSB?!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189 Ответы: #406

203. Сообщение от Аноним (203), 29-Апр-25, 09:06   +/
А остальное, как придётся.

Потому что гомункулы не равны между собой )

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179

205. Сообщение от Аноним (-), 29-Апр-25, 09:11   +/
> Зайди в магазин, купи 0xFA3 гвоздей

Нахрен тебе их столько? В таком количестве их обычно уже на вес норовят продавать. Кто ж их будет пересчитывать в таком объеме? :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

206. Сообщение от Аноним (192), 29-Апр-25, 09:13   +1 +/
Мож байтовый?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

207. Сообщение от Аноним (192), 29-Апр-25, 09:17   +/
А что эта? Новый виндопс?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201

208. Сообщение от BeLord (ok), 29-Апр-25, 09:28   –2 +/
А можно было сделать проще, у файла два атрибута номер и текстовое поле, система оперирует именами, а текстовое поле это та фигня, что отображается пользователю и в принципе не важно, что там записано и каким регистром.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #209, #210, #233, #381

209. Сообщение от BeLord (ok), 29-Апр-25, 09:29   +/
Система оперирует номерами, ачепятка-)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208

210. Сообщение от Ося Бендер (?), 29-Апр-25, 09:55   +1 +/
А можно было изначально не использовать объект (файл) из реального мира, но это была-бы уже другая история.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #229

211. Сообщение от 1 (??), 29-Апр-25, 10:08   +/
> Есть куча кода, для которого ip адрес это четыре байтовых числа через точку.

Вот это, как раз, и нестандартное использование IP адреса. Ведь известно, что IP адрес - это 4х байтовый беззнаковый int.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #225

212. Сообщение от 1 (??), 29-Апр-25, 10:09   +/
@то в штуках, килограммах, а может быть в фунтах ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

213. Сообщение от Аноним (109), 29-Апр-25, 10:10   +2 +/
> NTFS

Ну потому что они не выпускают по +100500 файловых систем раз в два месяца.
А улучшают NTFS.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150

214. Сообщение от 1 (??), 29-Апр-25, 10:13   +/
"Экслера не читали" (с) что там было про обходы сквида ? Сколько там прошло - лет 20-25 ?

Ну что, новое поколение пытается пройтись по тем же граблям :-)
И это неплохо, раз читать они так и не научились.

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

215. Сообщение от Аноним (109), 29-Апр-25, 10:14   +/
Ну че там, пацан то Товальдс, как он там.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201

216. Сообщение от 1 (??), 29-Апр-25, 10:15   +/
Ну дык пиши netmsk 0xffffff00
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

217. Сообщение от 1 (??), 29-Апр-25, 10:17   +/
Ага ! А ещё и с помощью эмодзи (где там птичий язык ?) ...

Даёшь приведение эмодзи в нижний регистр !!! И чтоб библиотека была на языке, который нельзя называть !

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

218. Сообщение от nrv (ok), 29-Апр-25, 10:24   +/
это да
но с другой стороны, не невыпускать же новые версии теперь
наверное можно указать уровень совместимости при создании, чтобы при смене дистриба не напороться
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

219. Сообщение от Аноним (237), 29-Апр-25, 10:32   +/
Во втором случае ping идет на 192.168.0.8. Почему?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #228, #245

220. Сообщение от Ilya Indigo (ok), 29-Апр-25, 10:34   +/
Эффективное хранения в памяти.
Для IPv4 ровно 4 байта нужно.
Да оно так и в любой системе и хранится, но интерпретация этих 4 байт может быть разной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

221. Сообщение от Аноним (109), 29-Апр-25, 10:37   +/
Он очень умен он очень умен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #333, #334

222. Сообщение от n00by (ok), 29-Апр-25, 10:46   +/
>>> Сердечки в имени файла.
>> За такое надо было бить по рукам с самого начала
> А за умляуты в имени файла тоже?

В первую очередь, бить надо за подобную гнилую софистику, когда демагог приравнивает спецсимволы (НЕ применяются для записи слов) к буквам (используются для записи слов) с целью развязать тупой спор.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #257, #355

223. Сообщение от n00by (ok), 29-Апр-25, 10:52   +2 +/
Внезапно, в NTFS могут быть '\0' в имени файла. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #247

224. Сообщение от Аноним (-), 29-Апр-25, 11:05   +/
> Суть не в том, хуже или лучше шестнадцатиричная запись десятичной. А в
> том, что вариант должен быть один, потому что это стандарт.

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

> Нет ни единой причины использовать много вариантов там, где можно использовать один.

В IPv6 придумали, блин, сразу несколько причин. Увы и ах.

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

Бы - не считается. Скажем для v6 сокращенная форма есть. Или еще вариант для link local. Не очень хорошо с их стороны но где ж вы тогда были?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #369

225. Сообщение от Аноним (-), 29-Апр-25, 11:08   +/
>> Есть куча кода, для которого ip адрес это четыре байтовых числа через точку.
> Вот это, как раз, и нестандартное использование IP адреса. Ведь известно, что
> IP адрес - это 4х байтовый беззнаковый int.

Int - это как правило нечто вообще хзкакого размера и endianess. А IPv4 это вполне себе 4 байта в вполне конкретном порядке. И нехило это как раз подчеркнуть.

Для IPv6... ну вы его по другому и не захотите особо записывать. Ибо если вы попробуете это как uint128 напечатать, да еще ктулху упаси в десятичной системе ... ух... удачи! Как видите этот номер как раз - не работал.

Разделение на октеты важно, оно позволяет видеть некторые вещи на глаз, скажем "тот же это subnet или нет". Удобно, быстро, визуально. Вы охренеете с какой скоростью devops ворочают такие вещи.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

226. Сообщение от тоже аноним (?), 29-Апр-25, 11:10   +/
Во всяких устройствах с недоношенным вводом, типа телевизоров, одно-двухзначные адреса как раз добиваются нулями в начале. И при этом работают как без нулей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #235

227. Сообщение от knikeemail (?), 29-Апр-25, 11:15   +/
Я извиняюсь, а японцы виндой пользуются? Там же все ФС регистронезависимые.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #306

228. Сообщение от Аноним (228), 29-Апр-25, 11:18   +/
Подсказка: ping 192.168.0.0x10
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #219 Ответы: #234

229. Сообщение от n00by (ok), 29-Апр-25, 11:26   +/
В том-то и дело. Изначально, у греков, "файл" - не объект, а процесс. "Как вы лодку назовёте, так она и поплывёт"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210

230. Сообщение от Аноним (230), 29-Апр-25, 11:39   +1 +/
Краткое руководство по опеннету:
1. ругать решения майкрософта
2. точно такие же решения Applе (да-да, регистронезависимость) замалчивать либо хвалить
3. ???
4. PROFIT
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #246, #252

231. Сообщение от Аноним (231), 29-Апр-25, 11:49   +/
Там ext4 нету. Но я знаю, где есть. :) Только куда их положить, чтобы заработало? (:
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #270

232. Сообщение от Аноним (231), 29-Апр-25, 11:51   +/
Куда именно воткнуть? (:
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #249

233. Сообщение от Аноним (233), 29-Апр-25, 11:59   +3 +/
Аноним изобрел i-node, какой ужас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208

234. Сообщение от Аноним (237), 29-Апр-25, 12:00   +/
Т.е. программу не смущает, что часть нужно интерпретировать в десятичном формате, и часть в шестнадцатиричном? Видимо, есть какой-то алгоритм, т.е. каждый октет по порядку проверяет на принадлежность к системе счисления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228

235. Сообщение от Аноним (237), 29-Апр-25, 12:03   +/
Видимо, это от самой программы зависит то, как она обрабатывает входные данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226

236. Сообщение от Аноним (237), 29-Апр-25, 12:13   +/
Даже ASCII далек от адекватного. Что уж говорить про Unicode.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

237. Сообщение от Аноним (237), 29-Апр-25, 12:16   +/
Типичная ситуация, когда борятся со следствием, а не решают проблему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #248

238. Сообщение от Анонимemail (238), 29-Апр-25, 12:17   +/
А как вы объясните zalgo ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

239. Сообщение от Аноним (237), 29-Апр-25, 12:26   +/
А за Unicode куда бить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

240. Сообщение от Аноним (237), 29-Апр-25, 12:31   +/
В чем удобство использования Юникода в именах файлов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #262

241. Сообщение от Аноним (237), 29-Апр-25, 12:34   +/
Ааа, ну с таким подходом можно что угодно нагромоздить. Было бы желание. Только пусть желающие это громоздят на своей системе, но нет же - навязывают остальному миру, ворую ресурсы цивилизации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #305

242. Сообщение от Аноним (242), 29-Апр-25, 12:40   +/
Как и регистрозависимость
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

243. Сообщение от ProfessorNavigator (ok), 29-Апр-25, 12:47   +/
> Более того - когда вы будете делать операции над числом 20 байтов
> размером - вы заодно невольно озаботитесь и endianess :) ибо есть
> минимум 2 способа записать такое число в память. Начиная с старшего
> байта, или с младшего.

Именно.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172

245. Сообщение от Аноним (245), 29-Апр-25, 13:08   +/
Внезапно 010 - это число в восьмиричной системе. Если в десятичную перевести как раз 8 будет. Вообще программирование это про числа а не так как сейчас многие привыкли....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #219 Ответы: #291

246. Сообщение от Ося Бендер (?), 29-Апр-25, 13:10   +/
> 1.

А ругань где увидели-то?

> 2.

Вживую никогда не пользовался и не интересовался, сказать нечего.

> 3.

А чего сказать-то хотели?

> 4.

Хотя-бы какая-нить св***ь, хотя-бы на банку пива подкинула! Нету желающих.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #230

247. Сообщение от Аноним (248), 29-Апр-25, 13:20   +1 +/
> Внезапно, в NTFS могут быть '\0' в имени файла. ;)

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

В линухе то такую диверсию зарубят прям на уровне сисколов. А вот в винде есть шансы что софт хорошенько налетит на том что такможнобыло с 1 стороны и 0x0 имеет специальное значение в C строках - с другой. Знаешь сколько сплойтов такого плана существует в этом мире? Видимо нет. Иначе не считал бы такие вещи - фичой. Вон там в ссылках написали несколько идей как юзеров винды можно огревать эксплойтами, через git и чего там еще, но это - далеко не полный список подарков им по линии ФС которые можно отгрузить при креативном подходе к вопросу.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223 Ответы: #329

248. Сообщение от Аноним (248), 29-Апр-25, 13:24   +3 +/
> Типичная ситуация, когда борятся со следствием, а не решают проблему.

Вот Торвальдс и сказал что решать надо - проблему. Как то - наворачивание потуг придавать байтам и их комбо специальный смысл вместо того чтобы просто и брутально сохранить как есть, с минимумом ограничений ("can't contain null and /") - ведет к великому множеству дурных факапов на ровном месте.

Зеня вон даже любезно подогнал примеры файликов как вам ВНЕЗАПНО можно попробовать перезапиать файло. Или стырить его - нарушив ACL. ЧСХ в виндах точно были факапы с тырингом внеплановых файлов через HTTP сервера, черех вулны с именами. По моему даже чуть ли не в IIS не говоря уж о других :)

Удобно же когда некто deny на СуперСекретныйФайл влепил, но он все равно - скачался как суперсекретныйфайл, если софт тупанул :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237 Ответы: #312

249. Сообщение от Аноним (248), 29-Апр-25, 13:27   +/
> Куда именно воткнуть? (:

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #232

250. Сообщение от ProfessorNavigator (ok), 29-Апр-25, 13:28   +/
> Совершенно не важно, как число лежит в памяти. Результат a+b не должен
> зависеть от расположения байт, это гарантирует язык программироавания (например, Си).
> endianess появляется, когда вы хотите отправить это число на другое устройчтво.

ЯП вам ничего не гарантирует в этом плане. Потому что порядок байт зависит от процессора. ЯП (если говорим про С/С++) вам гарантирует лишь то, что при операциях со стандартными типами результат вычислений будет корректным для данного конкретного типа данных (сейчас опускаем нюансы с обработкой переполнения типа). Потому что в большинстве случаев работа с типами диапазона 8-bit-64-bit и порядком байт "вшита" на уровне процессора. То же относится к типам float и double (для них даже отдельный сопроцессор бывает). Там есть нюансы - например 64-bit типы на 32-bit процессорах обычно обрабатываются "программно", а не "аппаратно" - я же сейчас говорю в общем и целом, про то, что актуально для архитектуры х86_64. Интересное начинается тогда, когда вам нужно всё это дело в каком-либо виде представлять человеку. Потому что вам нужно бинарное число, которое суть есть просто массив с n байт, преобразовать например в массив байт в кодировке ASCII (которая обычно для вывода чисел и используется). Т.е. вам нужно прочитать массив байт числа в определенном порядке, затем привести его к определённому основанию (например преобразовать в десятичное число, или в шестнадцатиричное) и вывести на печать в определённой кодировке. Операции приведения к основанию и перевода в кодировку обычно совмещены в единое целое.

Более того, стандартные типы чисел в С/С++ такие, какие они есть, потому что их делали на базе поведения процессоров. Поэтому в частности претензии растовиков к undefined behavior выглядят очень смешно для того, кто хоть немного понимает о чём речь. Иными словами, когда вам кто-то пытается втереть про undefined behavior для числовых типов в С/С++, знайте - этот человек просто ничего не понимает в программировании. И скорее всего продвигает чьи-то корыстные интересы. Но это так, к слову.
    
И да, если вам нужно передавать "сырые" байты с устройства на устройство, порядок байт может сказываться. Поэтому например для Internet Protocol (те самые ip адреса) чётко прописано, что для ipv4 адрес - это big endian 32-bit беззнаковое целое. А порт - big endian 16-bit беззнаковое целое. И если вы реализуете какой-то собственный сетевой протокол, то очень желательно сразу чётко оговаривать, в каком виде у вас будут передаваться числа.  


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189 Ответы: #260, #288

251. Сообщение от ProfessorNavigator (ok), 29-Апр-25, 13:44   +/
> А кстати, для каких? Всегда было любопытно

Я в код не смотрел, но подозреваю, что след тянется к Майкрософт. Они ж в последнее время активно начали в Линукс влазить и использовать его у себя. А имена файлов и папок без различия регистра - это именно их детище.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #319

252. Сообщение от Аноним (109), 29-Апр-25, 13:46   +/
> ругать решения майкрософта

Ну типа как найти отдушину определенную, в данном случае Microsoft.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #230

254. Сообщение от Аноним (254), 29-Апр-25, 14:10   +/
Только не говорите ему про базы данных - совсем расстроится... :) А вообще, нужно просто принять единый общемировой стандарт, включающий в себя однозначные правила преобразования регистра для каждого естественного языка (письменности) на планете. И в каждом коде должны быть реализованы только эти правила, а все остальные - исключены. Вроде, ничего сложного.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #258, #261, #299, #328

255. Сообщение от Аноним (23), 29-Апр-25, 14:17   –2 +/
> Строго говоря Юникод не знает таких понятий как "верхний регистр", "нижний регистр". Есть кодовая позиция, и есть прявязанный к конкретно данному коду, символ. И всё!

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

//ru.wikipedia.org/wiki/Русский_алфавит

"""
Ру́сский алфави́т (ру́сская а́збука) — алфавит русского языка, включающий 33 буквы.
"""

Ну это что за ересь? 33 звука - а не символа (буквы), ибо символы в таблице ниже там с разным регистром.

Аа, Бб, Вв, ... - и сколько в итоге букв? вот столько же и кодов в юникоде, и есть соглашение, что код условно 0001 - это символ "А", а 0002 - символ "а" это один и тот же звук в разном регистре. Для чего вообще придумали регистр символов это вообще другая тема обсуждения.

Но те же сердечки будучи символами условно "смузихлебного" алфавита разве имеют понятие регистра? "Черное сердечко" и "Красное сердечко" это два разных регистра одного сердечка получается? Или все же есть "Большое красное сердечко" и "маленькое красное сердечко"?

"""
(например, кто-то считает символы "❤" и "❤️" одинаковыми в режиме без учёта регистра, а кто-то нет)
"""

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #304, #357

256. Сообщение от Аноним (237), 29-Апр-25, 14:20   +/
Лично у меня и так к нему вопросов никаких нет. Я его не использую. Достаточно национальных кодировок.
Юникод - это попытка снова сделать одну кнопку для решения всех проблем, как, например, сделали с браузером. Впрочем с браузером скорее другое дело. Там, видимо, целенаправленно делали все для того, чтобы влезть каждому в ПК.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #290

257. Сообщение от Аноним (23), 29-Апр-25, 14:24   +/
> (НЕ применяются для записи слов)

каким кодом в юникод закодирована "Ritratto di Monna Lisa del Giocondo"?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222 Ответы: #327

258. Сообщение от Аноним (237), 29-Апр-25, 14:30   +1 +/
ASCII качественно не смогли сделать... Что уж про остальное говорить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #254 Ответы: #277

259. Сообщение от Аноним (259), 29-Апр-25, 14:32    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

260. Сообщение от Аноним (260), 29-Апр-25, 14:38   +/
> что их делали на базе поведения процессоров. Поэтому в частности претензии
> растовиков к undefined behavior выглядят очень смешно для того, кто хоть
> немного понимает о чём речь.

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

В частности то что сишка делает с signed int over/underflow и integer promition это за гранью добра и зла. И с enum - тоже.

В хрусте хватило ума хотя-бы не пытаться заметать проблему под ковер а честно пофиксить. Да, путем усложнения компилера. Но 1 раз наверное можно и подраспереться чтобы ВООБЩЕ ВСЕЙ ПЛАНЕТОЙ не огребать глупейшие баги, оптом, где их быть не должно. В C23 и соотв C++ комитет ьбакланов даже чуть попустило, signed int теперь только в twos complement можно, и все остальное noncompliant. Но, блин, долбаные пасатижи, доделать до well defined behavior ДО КОНЦА - ИХ НЕ ХВАТИЛО. Чтобы wrap в этом случае был строго регламентирован.

> Иными словами, когда вам кто-то пытается
> втереть про undefined behavior для числовых типов в С/С++, знайте -
> этот человек просто ничего не понимает в программировании.

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

> И скорее всего продвигает чьи-то корыстные интересы. Но это так, к слову.

Или кто-то не понял что premature optimization is a root of all evil (c) D.Knuth.

> И да, если вам нужно передавать "сырые" байты с устройства на устройство,
> порядок байт может сказываться. Поэтому например для Internet Protocol (те самые
> ip адреса) чётко прописано, что для ipv4 адрес - это big
> endian 32-bit беззнаковое целое. А порт - big endian 16-bit беззнаковое
> целое. И если вы реализуете какой-то собственный сетевой протокол, то очень
> желательно сразу чётко оговаривать, в каком виде у вас будут передаваться
> числа.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #272

261. Сообщение от Rollo99email (ok), 29-Апр-25, 14:43   +/
Вероятно когда-нибудь так и будет.

Но пока есть проблемы и неочевидные подводные камни.
Вот хорошая статья на эту тему в переводе:
https://habr.com/ru/articles/525608/
Особенно интересен момент с важностью локали, хотя всегда считал, что Unicode придумали, чтобы этой проблемы не существовало.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #254

262. Сообщение от Аноним (-), 29-Апр-25, 14:49   +1 +/
> В чем удобство использования Юникода в именах файлов?

Можно без обиняков обозвать файло "неведомая долбаная фигня ❤ и ❤️" и это даже будет корректно оотображаться. Но если удумать еще и регистр этого процессить... выйдет неведомая долбаная фигня! :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #240

263. Сообщение от Аноним (-), 29-Апр-25, 14:51   +/
>> Поздно рассуждать о боржоми, когда почки накрылись. Само появление не-ascii символов в
>> именах файлов открыло ящик пандоры.
> Как открыло, так и закроет. Немного боли и придет стандартизация.

Который оно там год уже "приходит"? А тем временем нас заваливает пачками глупых вулнов и просто глюков на ровном месте.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #307

264. Сообщение от PnD (??), 29-Апр-25, 14:53   +/
Вот да. Может в 1970х где-то и экономили битик.
Но уже́ в 80х была ASCII-7 и аналоги (7 бит). 127 символов (и 0-й байт) для кодирования регистрозависимой латиницы — выше крыши.

* Я не настолько старый чтобы помнить причину изначально 7-битной кодировки. Но вроде в 8-й бит засовывали чётность для передачи по всяким-разным каналам.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #326

265. Сообщение от Ivanemail (??), 29-Апр-25, 14:59   +/
> однозначного, правильного и безошибочного пути выполнять данную операцию просто не существует

Да что там, даже однозначного, правильного и безошибочного способа определить ширину произвольного набора кодовых точек Юникода в экранных знакоместах шрифта с фиксированной шириной — тоже не существует. Разные либы разных версий дают разное. В far2l неплохо так задолбались с этим

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

266. Сообщение от Bottle (?), 29-Апр-25, 15:56   +/
Затем, что когда-то иероглифы и были этими самыми смайликами, только не всегда цветными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

269. Сообщение от Аноним (109), 29-Апр-25, 16:10   +/
Товальдс, офигенный, парень.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179

270. Сообщение от Аноним (72), 29-Апр-25, 16:26   +/
> Там ext4 нету

Есть. ext2_x64.efi -- общий драйвер для ФС семейства ext*

> Только куда их положить, чтобы заработало?

Сначала по этой инструкции https://github.com/pbatard/efifs/wiki/Adding-a-driver-to-a-U... (раздел "Creating the UEFI firmware module") драйвер нужно преобразовать в формат, понятный прошивке. Потом любым рабочим способом добавляешь получившийся модуль в образ биоса, после чего прошиваешь. Только учти, что обычными утилитами модифицированную прошивку не залить -- нужно либо снимать защиту вручную (как -- гугли сам, я уже не помню деталей), либо использовать программатор.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #231 Ответы: #402

271. Сообщение от Zenitur (ok), 29-Апр-25, 16:39   +1 +/
> Гнилой виндузоид - палится сразу.

А зачем останавливаться на одних только лишь именах файлов? Можно ещё емейлы делать типа lena@mailbox.org, Lena@mailbox.org, LeNa@mailbox.org, lenA@mailbox.org... Да чего уж там - сразу URL-ы серверов. Вот набираешь ты в адресной строке не google.com, а Google.com, и попадаешь на другой сайт. А ещё имена улиц можно делать "некрасова" и "Некрасива", и чтобы они находились в разных частях города. Не нравится? Ты что не современный?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #283, #285, #287

272. Сообщение от ProfessorNavigator (ok), 29-Апр-25, 16:40   +/
> Вообще-то ничего смешного тут нет. Ибо упростили жизнь комитету и имплементерам компилера
> - ценой дохрена левых багов которых вообще быть не должно было.

Не обижайтесь, но это именно, что смешно ;) Проще говоря, вы - живая иллюстрация моих слов. Почему - объясню чуть ниже.

> В частности то что сишка делает с signed int over/underflow и integer
> promition это за гранью добра и зла. И с enum -
> тоже.

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

> В хрусте хватило ума хотя-бы не пытаться заметать проблему под ковер а
> честно пофиксить. Да, путем усложнения компилера. Но 1 раз наверное можно
> и подраспереться чтобы ВООБЩЕ ВСЕЙ ПЛАНЕТОЙ не огребать глупейшие баги, оптом,
> где их быть не должно. В C23 и соотв C++ комитет
> ьбакланов даже чуть попустило, signed int теперь только в twos complement
> можно, и все остальное noncompliant. Но, блин, долбаные пасатижи, доделать до
> well defined behavior ДО КОНЦА - ИХ НЕ ХВАТИЛО. Чтобы wrap
> в этом случае был строго регламентирован.

Ну т.е. "махровый сишник" даже не подозревает о существовании типов фиксированной длины.
Всяких там uint32_t и подобного. И не понимает, для чего нужны типы int, unsigned int, и почему они именно такие. Ну-ну.

> Или что вероятнее - задолбался прыгать по граблям которых быть вообще не
> должно было. Ибо правила си в работе с integer оставляют желать
> много лучшего. Это я как махровый сишник говорю. Это источник грабель.

Это вы мне как очередной, нанятый за копеечку строчить комментарии, говорите. Уж извините за прямоту. Понимаю, жизнь бывает тяжёлая, но не стоит таким заниматься. Это вам же и отольётся в будущем, когда очередной, наслушавшийся вас неофит вообразит, что очередной же "суперсовременный" ЯП решит все проблемы за него и полезет писать на нём прошивку системы управления ядерным реактором или автопилотом самолёта. А источник грабель в данном случае лишь "программист", который не понимает как это всё работает.

> Или кто-то не понял что premature optimization is a root of all
> evil (c) D.Knuth.

А это здесь причём?))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #260 Ответы: #341

273. Сообщение от Аноним (-), 29-Апр-25, 16:40   +/
Комитет стандартизирующий Юникод очень экономно подходит к "расходованию" кодовых позиций. Если комитет решил, что латинское "A" и кириллическое "А" разные символы значит на то были веские основания. Когда решают поместить какой либо символ в состав Юникода, тщательно изучается история данного символа.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195 Ответы: #363

274. Сообщение от Аноним (274), 29-Апр-25, 17:15   –1 +/
Просто на program files вешаешь регистронезависимость. А сама винда сделана так чтобы работать норм и с регистрозависимостью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #310

275. Сообщение от Аноним (109), 29-Апр-25, 17:32   +/
Товальдс, офигенный парень.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188

276. Сообщение от Аноним (276), 29-Апр-25, 17:37   +/
>EFI system partition уже можно в ext4 ?!!

А почему не в NTFS? Причем легаси и некорректное преобразование? Там где нужен FAT пусть будет FAT с его требованиями.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

277. Сообщение от Аноним (254), 29-Апр-25, 17:43   +/
Вот для ASCII я бы такое и не решился предложить - там в плане кодирования национальных букв всё было неоднозначно изначально. Но мы же здесь не ASCII обсуждаем, а вполне однозначный в этом плане Unicode, правильно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258

278. Сообщение от Аноним (276), 29-Апр-25, 17:46   +/
Есть разные нотации одного и того же числа (двоичная, восьмеричная, десятичная, шестнадцатеричная, с 8-битными полями, разделенными точкой и др)  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

279. Сообщение от Аноним (355), 29-Апр-25, 17:47   –2 +/
Возможно. Практичное решение, которое куда лучше, чем «мы не знаем как сделать идеально, поэтому вообще никак делать не будем». Регистрозависимость — костыль, растущий из отсутствия строк в Си и экономики вычислений семидесятых, когда действительно тратить процессорное время и память на приведение регистров (и уж тем более на такую роскошь как произвольная строка) было непозволительно. Так пятьдесят лет и мучаемся с античеловеческим поведением файловых систем. Ну зато компьютеру так удобнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179

280. Сообщение от Аноним (355), 29-Апр-25, 17:48   –1 +/
Ах, да, stable api nonsense. Каждый раз забываю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197

281. Сообщение от Аноним (281), 29-Апр-25, 17:50   +/
Вас юбут, а вам всё равно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

282. Сообщение от Аноним (276), 29-Апр-25, 17:52   +/
IP без маски ничего не стоит. Как его доставлять, в какую подсеть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

283. Сообщение от Аноним (355), 29-Апр-25, 17:54   +1 +/
> Можно ещё емейлы делать типа lena@mailbox.org, Lena@mailbox.org, LeNa@mailbox.org, lenA@mailbox.org

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #271 Ответы: #323

284. Сообщение от Аноним (276), 29-Апр-25, 17:55   +/
>Зайди в магазин, купи 0xFA3 гвоздей

Если покупать в маркетплейсе, то может быть предусмотрен преобразователь из hex

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

285. Сообщение от Аноним (285), 29-Апр-25, 18:03   +/
Система обработки почты автоматически переводит все буквы в нижний регистр, независимо от того, как они введены.

То есть разных регистров нет в принципе.

И да на названия улиц распространяются правила русского языка.
Так что они пишутся с большой буквы за которой следуют маленькие.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #271

286. Сообщение от Аноним (276), 29-Апр-25, 18:17   +/
>Вас это удивит, но наберите в браузере http://3644916501/63149

http://033120201425/63149 то же самое.
http://0xD9410315/63149 то же самое.
Всё равно ip адреса маршрутизируются в устройствах, работающих с двоичным представлением.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

287. Сообщение от Аноним (-), 29-Апр-25, 18:26   +/
> А зачем останавливаться на одних только лишь именах файлов? Можно ещё емейлы
> делать типа lena@mailbox.org, Lena@mailbox.org, LeNa@mailbox.org, lenA@mailbox.org...

А почему бы и нет? Сейчас оно сделано именно так, потому что RFC822 делался еще для ARPA Internet. Это дремучая древность - первая версия опубликована в 1982 году, а начала разрабатываться еще раньше.

> Да чего уж там - сразу URL-ы серверов. Вот набираешь ты
> в адресной строке не google.com, а Google.com, и попадаешь на другой сайт.

Тем не менее, некоторые части UR как раз case sensitive.
Вот прям здесь и сейчас. https://www.opennet.me/opennews/art.shtml?num=63149 открывается.
А https://www.opennet.me/opennews/Art.shtml?num=63149 - нет.

> А ещё имена улиц можно делать "некрасова" и "Некрасива", и
> чтобы они находились в разных частях города. Не нравится? Ты что
> не современный?

Ты же понимаешь что название улиц еще еще более древнее легаси?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #271

288. Сообщение от Аноним (288), 29-Апр-25, 19:17   +/
> Более того, стандартные типы чисел в С/С++ такие, какие они есть, потому что их делали на базе поведения процессоров. Поэтому в частности претензии растовиков к undefined behavior выглядят очень смешно для того, кто хоть немного понимает о чём речь.

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


// Должно сработать, ведь С это переносимый ассемблер, правильно?
if (a + b < a) {
//overflow...
}

либо заменяет его "эквивалентным":

if (b < 0) {
//overflow?
}

не смотря на то, что программист знает ассемблер и точно знает, как на его целевой архитектуре (на любой современной!) переполняются целочисленные.

>Иными словами, когда вам кто-то пытается втереть про undefined behavior для числовых типов в С/С++, знайте - этот человек просто ничего не понимает в программировании.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #295, #350, #354

289. Сообщение от Аноним (276), 29-Апр-25, 19:22   +/
>А есть хотя бы одна причина использовать какие-то числа кроме ОБЫЧНЫХ ?

hex-редакторы придумали и применяются не зря. Там используется hex-нотация, потому что удобно.
IP адрес удобно представлять как двоичное число, потому что сейчас применяется "плавающие" маски сети. Вот пример: CIDR:    142.250.0.0/15

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #388

290. Сообщение от Аноним (-), 29-Апр-25, 19:26   +2 +/
Ты не прав. Юникод, Международная система единиц - лучшие избретения человечества.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256 Ответы: #311

291. Сообщение от Аноним (276), 29-Апр-25, 19:27   +/
>Внезапно 010 - это число в восьмиричной системе.

Это оговоренная нотация числа восемь. Где возможно обозначают подстрочником.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #373

293. Сообщение от Аноним (276), 29-Апр-25, 19:30   +/
ping 3644916501 вполне работает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

295. Сообщение от ProfessorNavigator (ok), 29-Апр-25, 19:32   +/
Ну всё, набежали... Ребята, я вам уже пару раз говорил - методичку смените, а то надоели со своим бредом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288

296. Сообщение от Аноним (276), 29-Апр-25, 19:33   +/
>сердечки в юникоде еще и размер меняют?

Есть описание символа. А как его изобразить решает дизайнер.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

297. Сообщение от Ананоним (?), 29-Апр-25, 19:34   +/
Страшно, очень страшно, мы не знаем что это такое, если бы мы знали, что это такое, но мы не знаем, что это такое.
Ответить | Правка | Наверх | Cообщить модератору

299. Сообщение от Аноним (-), 29-Апр-25, 19:39   +/
>Только не говорите ему про базы данных - совсем расстроится

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #254

300. Сообщение от Аноним (300), 29-Апр-25, 19:44   +/
Ну, так, верно же. Если фс регистры зависима, то человек на глаз способен отличить один символ от другого. Главное же, что линукс безопасен, а то, что эта безопасность приводит к уязвимостям - не проблема линукса. :D
Ответить | Правка | Наверх | Cообщить модератору

302. Сообщение от penetrator (?), 29-Апр-25, 22:00   +/
но не в UEFI
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

303. Сообщение от penetrator (?), 29-Апр-25, 22:03   +/
C0.A8.00.01

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

304. Сообщение от Аноним (304), 29-Апр-25, 22:36   +/
>  33 звука

Е, Ё, Ю и Я все вместе мерзко хихикают, рядом прыскают от смеха Ц и Щ, а Ь и Ъ смотрят молча, с недоумением.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #255 Ответы: #314

305. Сообщение от Аноним (304), 29-Апр-25, 22:43    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241

306. Сообщение от Аноним (304), 29-Апр-25, 22:49   +/
Ответ простой, надо скачать с серверов MS исошник десяточки с японской локализацией, накатить в виртуалку и посмотреть как это выглядит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #227

307. Сообщение от Аноним (304), 29-Апр-25, 22:53   +/
Вот тебе вместо кучи национальных кодировок вместе или вместо ASCII подвезли юникод, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263

308. Сообщение от _kp (ok), 29-Апр-25, 23:12   +/
Смотря какой DOS. DOS 6.22 при желании поддерживал длинные имена файлов. :)
Исторически FAT12, FAT16 регистрозависимые, но в именах файлов возможно только заглавные буквы. И проблем не было.

Регистронезависимость в FAT принесена с добавлением длинных имен файлов.
А вот NTFS изначально создавалась регистронезависимой.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #331

309. Сообщение от _kp (ok), 29-Апр-25, 23:20   +/
>>Даже на больших флешках, таких как 128 Гб, FAT32 прекрасно себя чувствует.

А писать что нибудь пробовали в "больших" объёмах. Как скорости? :)
ExFAT тоже по скорости плох, и плох везде, если только не писать исключительно фильмы и архивы.

И кстати, флешка 0.1ТБ, это вовсе не большая флешка. Но это не важно. Суть в том, что большие флешки берут, очевидно что бы на них писать. И на больших объемах записи, влияние неудачной файловой системы может увеличить скорость с минут до часов. А в остальном с FAT почти все хорошо. :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #325

310. Сообщение от _kp (ok), 29-Апр-25, 23:24   +/
>>винда сделана так чтобы работать норм и с регистрозависимостью

Нет. Точнее очень много Win-ПО не переносят регистрозависимость.
Ставите сторонний драйвер регистронезависимой FS, и обнаруживаете что на нем много что не заработает.  
На Маках тоже иногда попадается старое/портированное ПО, не переносящее регистрозависимость, и для него приходится делать образ или раздельчик с регистронезависимой FS.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #274 Ответы: #316

311. Сообщение от _kp (ok), 29-Апр-25, 23:34   +/
> Ты не прав. Юникод, Международная система единиц - лучшие избретения человечества.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #290 Ответы: #377

312. Сообщение от Аноним (312), 29-Апр-25, 23:47   +2 +/
вот именно koi8r (щщщютка)
Я себе слабо представляю, чтобы у человека в паспорте были сердечки вместо букв в имени, на номерах домов и квартир мордочки кошечек и собачек вместо цифр, и ладошки с модификатором цвета кожи вместо чисел в ценниках на товарах.
Имена файлов и каталогов должны быть в усеченном подмножестве.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #248 Ответы: #338, #378, #413

313. Сообщение от Аноним (313), 30-Апр-25, 00:39   +/
Э, нет.
Компьютеру для различения разных файлов достаточно числа, большинству систем хватит 64 бита. Корпоративным свалкам наверное 128 бит впору.
Остальное - от лукавого.

Диссертация - в файле 1254785421, порнуха в 1254785241
Не перепутай.

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

314. Сообщение от Аноним (23), 30-Апр-25, 00:41   +/
> Е, Ё, Ю и Я все вместе мерзко хихикают, рядом прыскают от
> смеха Ц и Щ, а Ь и Ъ смотрят молча, с
> недоумением.

то есть вы не издаете звуки при чтении этих букв?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304 Ответы: #315

315. Сообщение от ProfessorNavigator (ok), 30-Апр-25, 01:18   +/
> то есть вы не издаете звуки при чтении этих букв?

Звуки то он издаёт. Только вот звуков в алфавите чуть больше, чем вам кажется. Е, Ё, Ю, Я - по два звука. Подучите фонетику родного языка;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #314 Ответы: #320

316. Сообщение от Аноним (316), 30-Апр-25, 01:25   +/
И? Это ПО ставится в Program Files. На него вешаешь какую надо настройку - и всё работает из коробки. Пути к файлам же пользователя не хардкодят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #310

317. Сообщение от Аноним (319), 30-Апр-25, 01:58   +1 +/
https://static.sched.com/hosted_files/osseu2020/ea/Gabriel_K...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #318

318. Сообщение от Аноним (319), 30-Апр-25, 02:02   +/
Ах, да. Страница 10.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #317

319. Сообщение от Аноним (319), 30-Апр-25, 02:03   +/
> но подозреваю, что след тянется к Майкрософт.

Так и есть.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251

320. Сообщение от Аноним (23), 30-Апр-25, 02:23   +/
Вот такой даже придумали :)

//ru.wikipedia.org/wiki/Фонетический_алфавит

> Только вот звуков в алфавите чуть больше, чем вам кажется. Е, Ё, Ю, Я - по два звука.

42 звука - там твердые мягкие и всякая ересь.


> Подучите фонетику родного языка;)

Не родной он мне вовсе. Спросим у чатгопоты:

"""
сколько звуков было до внедрения буквы твердый знак и мягкий знак?

-----

До внедрения твердых и мягких знаков в старорусском языке было несколько особенностей в произношении и письменности, но в целом их появление связано с реформами, произведёнными в XI-XIV веках.

До этого времени в русском языке не было выделения мягкости в произношении согласных так, как это стало возможным с помощью мягкого знака (ь) и твёрдого знака (ъ). Но важно отметить, что гласные звуки и некоторые согласные существовали и без этих букв.

Вот как это выглядело:

До внедрения твёрдого и мягкого знаков:
Звуков было меньше — многие звуки, которые позже стали мягкими или твёрдыми с помощью этих знаков, просто не различались по звучанию. То есть, не было необходимости в разделении звуков типа [т'] (мягкое т) и [т] (твёрдое т).

Мягкость и твёрдость согласных в значительной степени стали диакритическими знаками позже, когда язык стал более строгим в разделении этих звуков. В старославянской письменности (когда появлялись первые кириллические алфавиты) мягкость передавалась с помощью особых букв (ь и ъ) и через контекст.

Количество звуков было меньше, поскольку:

Многие звуки не делились на твёрдые и мягкие.

Мягкость согласных (например, [к'] или [д']) передавалась просто по контексту и не обозначалась отдельно.

Как выглядело количество звуков до этих знаков:
В русском языке было примерно 35-36 звуков (без учёта твёрдого и мягкого знаков).

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

Что именно изменилось с введением знаков:
В старославянском и более древних вариантах славянских языков не было чёткого разделения на мягкие и твёрдые согласные. Эти звуки не передавались с помощью конкретных букв.

С развитием языка и внедрением мягкого и твёрдого знаков появилась возможность чётко различать пары звуков, такие как [т'] и [т], [с'] и [с], [к'] и [к].

Таким образом, до внедрения ь и ъ звуков было меньше, так как мягкость и твёрдость не отделялись так явно. Мягкий и твёрдый знак стали обязательными элементами, благодаря которым звуков стало больше.

Надеюсь, это объяснение помогает! Если хочешь более подробную информацию о развитии этих звуков, могу рассказать!

"""
вот так вот :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #315 Ответы: #336

321. Сообщение от Аноним10084 и 1008465039 (?), 30-Апр-25, 03:51   +/
Я в начале подумал, что символы пик ♠️ и червей ♥️ некоторые считают одним. А потом пригляделся - там чёрное сердце ❤ и ❤️ и красное. И что интересно, клава Андроида при копировании и вставке в превьюшке показывает их как оба красные
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #339

322. Сообщение от maximnik0 (?), 30-Апр-25, 04:38   +1 +/
>Можешь реализовать, а мы посмотрим.

Уже реализовано, где-то уже не помню но скачивал UEFI драйвера для ext4,htfs,hfs,udf.
А так у многих плат в UEFI есть поддержка htfs,т.к более распространенная.

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

323. Сообщение от maximnik0 (?), 30-Апр-25, 06:43   +/
>забивают решительно все почтовые системы в мире

Не все забивают.Потому что есть стандарт внезапно с # в имени почтового ящика, позволяет на одном почтовом ящике кучу пользователей вешать.Вообще почта это ужасный набор костылей- но пространство имён даже позволяло сразу доставить письмо на телетайп.А так куда шлюзов только не было- Фидо,usenet,uuсp и т.д.А самые бородатые дяди могли получить /отправить письмо с помощью telnet .

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #283

324. Сообщение от bOOster (ok), 30-Апр-25, 07:05   +1 +/
Как-то даже и не странно что FreeBSD+ZFS не имеет никаких сложностей в вопросе Unicode - пользуйте UTF8.
А у оголтелых очередные грабли на ровном месте.
Ответить | Правка | Наверх | Cообщить модератору

325. Сообщение от maximnik0 (?), 30-Апр-25, 09:18   +/
> писать что нибудь пробовали в "больших" объёмах. Как скорости? :)

Нормально там по скорости,не хуже чем у UDF.Нужно нормальные флэшки использовать,а не с 100 мгб кэшем а остальные тормоз.
Но UDF хрен чем отремонтировать,а exfat чиниться.Да, обычно ошибки в метаданных,но бывает что и данные страдают.А если вы имеете ввиду миллион файлов в папке - нечего лучше ext4 с индексом и отключённом журналом не придумали.Ну можно ещё пошаманить с btrfs,все оптимизировав,но чем она тогда от exfat будет отличаться не понятно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #309

326. Сообщение от Аноним (326), 30-Апр-25, 09:30   +/
> Я не настолько старый чтобы помнить причину изначально 7-битной кодировки.

Шоб по телетайпу слать и вводить тупой текст. 8 бит это бит чётности для проверок ошибок. Да и первые модемы так же работали. Всё сильно упрощалось и подпрограммы для работы с этим занимали несколько инструкций - было очень актуально, когда всё-всё-всё (логику, "дрова" и т.п.) надо было запихнуть в 32 кб памяти.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264

327. Сообщение от n00by (ok), 30-Апр-25, 09:54   +/
Советую перечитать и попробовать выдернуть из контекста более подходящее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #257

328. Сообщение от PnD (??), 30-Апр-25, 09:58   +/
Э, а что не так с БД?
Во всяких SQL и прочих LDAP регистронезависимый синтаксис использует даже не ASCII, а достаточно узкое его подмножество (гуглить в сторону ASN ("Abstract Syntax Notation")).
Вот там можно определить понятия (функции) для upper|lower cases.
А для самих данных всё тут же становится опять интересным. Вплоть до изменения порядка сортировки (collation) между релизами какой-нибудь i18n.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #254

329. Сообщение от n00by (ok), 30-Апр-25, 10:03   +/
Советую в следующий раз не лепить нелепый наброс на Микростфт, а задать вопрос. Тогда бы я ответил, что Анонимный эксперт не сможет создать такой файл. А сейчас добавлю, что по причине недостатка знаний, и даже не буду уточнять номер RFC. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247 Ответы: #348

330. Сообщение от Аноним (326), 30-Апр-25, 10:03   +/
Причём тут Микрософт? У микрософта это всего лишь следствие, что в cp/m файлы были всегда в верхнем регистре. Т.е. писать мог по любому, но файл всегда назывался в верхнем регистре и соответственно в первых досах было так же, ну а потом сделали уже регистронезависимость и тогда это не было проблемой - 7 бит, как и 640 кб всем хватит.

Ну и попробуй объяснить условному Васяну, что файл ДОКУМЕНТВАСИ.XLSX и документваси.xlsx как-то различаются. Ведь и ежу понятно, что это один и тот же файл. Ну и компы они не для яфинов, они для Васянов, поэтому у Микрософта всё и сделано правильно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #343, #352

331. Сообщение от n00by (ok), 30-Апр-25, 10:13   +1 +/
> А вот NTFS изначально создавалась регистронезависимой.

Смотрим параметр ObjectAttributes в NtCreateFile
https://learn.microsoft.com/en-us/windows/win32/api/winternl...

а в нём ULONG Attributes

Is a set of flags that controls the file object attributes. This value can be zero or OBJ_CASE_INSENSITIVE, which indicates that name-lookup code should ignore the case of the ObjectName member rather than performing an exact-match search. The value OBJ_INHERIT is irrelevant to device and intermediate drivers.

Флаг OBJ_CASE_INSENSITIVE указывает коду поиска имён игнорировать регистр. То есть по умолчанию поиск регистрозависим. При этом надо понимать, что "поиск в ФС" и "ФС" не одно и тоже.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #308 Ответы: #340

332. Сообщение от Аноним (326), 30-Апр-25, 10:25   +/
>Да наверняка сделали только для широкоизвестных алфавитов.

Потому что там utf-16 (как и в java) и upper/lower не скачет по размеру ну и +- проще и понятнее.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179

333. Сообщение от Аноним (-), 30-Апр-25, 11:04   +/
Ну так да. Я ведь в отличии от тебя для известных компаний создавал файловую систему. И прекрасно понимаю что дополнительная информация о пути имени файла созданет возможность её поддержки и исправления. Локаль в отличии от имени является служебной информацией и в случае обнаружения каких проблем всегда что-то можно исправить и даже более - версионировать. И это то что до тебя не доходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221 Ответы: #375

334. Сообщение от Аноним (-), 30-Апр-25, 11:09   +/
И да, проблема в кодировке. Если будет кодировка в которой нет похожих и повторяющихся символов и нет вредоносных символов, то и результат может быть неплохой. Да часть символов всегда можно зарезервировать под исправления. Но Линукс в эту сторону даже не смотрит. Почему? Потому что это весьма много работы, а они хотят сосредоточится на других задачах. Вот чесно бы так сказал бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221

335. Сообщение от fuggy (ok), 30-Апр-25, 11:23   +/
Кроме того есть буквы которые имеют по 2 варианта. То есть строка если преобразовать в верхний, а потом в нижний регистр не будет равна самой себе. Кроме того может не совпасть даже длина, потому что есть хитрый символ, который преобразуется в 2 символа. Короче с юникодом всё сложно, поэтому правильно Линус говорит, что регистронезависимые ФС это костыль.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136

336. Сообщение от ProfessorNavigator (ok), 30-Апр-25, 11:45   +/
> Вот такой даже придумали :)
> //ru.wikipedia.org/wiki/Фонетический_алфавит

Да, я в курсе. Не знаю как сейчас, раньше этому в школе обучали. Классе в 7-8 примерно, если я правильно помню. Подзабыл уже за давностью лет))

> Не родной он мне вовсе.

Тогда извините - вам простительно. А какой родной? Если не секрет, конечно.  

> вот так вот :)

Последняя значительная реформа правил русского языка была после Революции. Лучше ориентироваться на неё.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #320 Ответы: #344

337. Сообщение от Roman Dyaba (ok), 30-Апр-25, 12:02   +/
Правильно сделал !
Ответить | Правка | Наверх | Cообщить модератору

338. Сообщение от Аноним (-), 30-Апр-25, 12:19   +/
> Я себе слабо представляю, чтобы у человека в паспорте были сердечки вместо
> букв в имени, на номерах домов и квартир мордочки кошечек и
> собачек вместо цифр, и ладошки с модификатором цвета кожи вместо чисел
> в ценниках на товарах.

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

> Имена файлов и каталогов должны быть в усеченном подмножестве.

Как по мне - меня устраивает подмножество "everything except null and /". Главное не пытаться искать специальный смысл в этих байтах - и жевать их как отдала ФС. Иначе - возможно горе от ума, как с case folding.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #312 Ответы: #392, #401

339. Сообщение от Аноним (109), 30-Апр-25, 12:37   +/
Товальдс, все таки клевый чувак, изобрел ♠️ и ♥️.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #321

340. Сообщение от _kp (ok), 30-Апр-25, 12:38   +/
> коду поиска имён игнорировать регистр.

Это костылик только для кода API открытия файла.
А например получил список файлов в каталоге, и.. нужно знать а какая там файловая система, с какими атрибутами? И не переносил ли кто файлы на флешке, пересылал, и не похерил атрибуты? :)

> OBJ_CASE_INSENSITIVE.. То есть по умолчанию поиск регистрозависим.

Нет, тут состояния "как нибудь" и "игнорировать".
Состояние "как нибудь", зависит от того как примонтирован ресурс.
А вот монтировать NTFS с явной чувствительностью к регистру, сейчас точно можно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #331

341. Сообщение от Аноним (-), 30-Апр-25, 12:51   +/
> Не обижайтесь, но это именно, что смешно ;) Проще говоря, вы -
> живая иллюстрация моих слов. Почему - объясню чуть ниже.

Это вы - живая иллюстрация. Антипаттернов в программировании. Живой пример как писать софт вообще совсем не надо. От юзабилити - до антибаг кодинга и ИБ! Можно выбрать любое направление - и не прогадать.

Почему? Потому что достаточно посмотреть на ваш софт. Его скрины. Сорцы и вообще.

> Вот это например. "сишка" ничего с этим не делает, а делает процессор.

Сэр, вы нифига в программировании не поняли! Если бы я хотел знать что делает процессор - я бы сишку брать не стал, и взял бы асм. Там это по крайней мере - можно. А вот именно в сишке - вы даже долбаный флаг Carry посмотреть вот так по простому - не сможете. И получается максимально дурацкая ситуация. Даже просто определить - переполнится ли вот тут или нет в сишке это тот еще квест. Особенно с дефолтными типами. Какой процент програмеров успешно с ним справляется - вы поняли! И некоторые вещи не очень криво делаются - только левыми builtin которые не стандартные. Хотя можно еще превратить код в квест по брейнфаку и посмотреть сколько програмеров облажается в его понимании. Что так no-win, что так.

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

> И если у вас переполнение - то вы сам себе злобный
> буратино, ибо не учли, что у вас числа могут "выезжать" за
> границы используемого типа данных.

Во первых можно поговорить как в сишке эти самые типы определены. И как это работает по дефолту. Int - это сколько? Переполнится он вот тут? А на другой платформе? Ответ на этот простой вопрос - знатнейший брейнфак. Особенно если еще и какие-то операции с числами делать. А с signed это вообще - минное поле.

> А процессор делает ровно то, что вы ему сказали делать.

Я никакому процессору вообще ничего не говорил делать. Это заявление применимо только к программированию на ассемблере. Сишку же я юзал как раз чтобы на ассемблере не програмить и не лезть в интимные детали конкретного процессора, получив ПОРТАБЕЛЬНЫЙ код.

> Ну т.е. "махровый сишник" даже не подозревает о существовании типов фиксированной длины.

Т.е. я ими активно пользуюсь. Особенно в фирмварях и "новых" апях моего разлива. Но и это тоже полкило грабель.
1) Promotion типов у C все равно дико горбатый и грабельный. А 1, 1U, 1UL, и 1ULL это 4 довольно разные вещи.
2) Для enum хоть какой-то намек на адекват появился - в C23. До этого вы вообще даже так с ходу не знаете - какой у этой фигни получился вот тут тип.
3) В сях так то еще есть - препроцессор. И им порой рюхают в компилтайм разные вещи. Только он - не сишка. Но - математику тоже умеет. И даже сильно больше чем математику. Он "почти тюринг полный" и на нем можно делать весьма хитрые конструкции, прелесть которых в том что все это обсчитается компилтайм, и можно сочетать понятную двуногому запись с эффективностью в run time. Проблема в том что комитет тупарей вон то к вот этому совсем никак не применял. И про эти типы препроцессор ничего не знает.

> Всяких там uint32_t и подобного. И не понимает, для чего нужны типы
> int, unsigned int, и почему они именно такие. Ну-ну.

У меня этих uint32_t имхо сильно больше чем у вас. И тем не менее, баги на вон том - лезут. У почти всех. Чисто статистически. И в очередной раз затыкая "int" underflow за дидом при неожиданных (какая неожиданность!) внешних данных - это может и надоесть. И захотеться - более радикального решения этой проблемы. Так и появился хруст...

> Это вы мне как очередной, нанятый за копеечку строчить комментарии, говорите.

Мне никто ни цента за это не платит. Я просто люблю качественный софт и не люблю глупые баги и вулны на ровном месте. Так что при всей симпатии к сишке - было бы глупо игнорить недостаки или даунплеить удачные решения откровенно за@#$ших уже проблем.

> Уж извините за прямоту. Понимаю, жизнь бывает тяжёлая, но не стоит таким
> заниматься. Это вам же и отольётся в будущем, когда очередной, наслушавшийся
> вас неофит вообразит, что очередной же "суперсовременный" ЯП решит все проблемы

Как я уже сказал - мой профит никак не зависит от коментов на опеннете. И хрустом я не пользуюсь. Но знаете, когда gccrs дойдет до кондиции - я подумаю на эту тему. Потому что инженерное решение задолбавших проблем - в частности пусть и ценой усложнения компилера - таки лучше чем в i++'й раз запрыгивать на те же грабли с пофигом комитета тупарей на мои (и вообще отраслевые) проблемы.

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

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

>> Или кто-то не понял что premature optimization is a root of all
>> evil (c) D.Knuth.
> А это здесь причём?))

При том что это, кажется, про вас... процессор ему там что-то делает. В сишке. Ога. Где в сишке абстракции чтобы состояние этого процессора вообще видеть? А, нигде? :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #272 Ответы: #356

342. Сообщение от _kp (ok), 30-Апр-25, 13:14   +/
>правильное решение - прямо в винде включить регистрозависимые

Ой скопытится.. Вам мало что значительная часть ПО от не латиницы в путях выпадает в осадок?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #371

343. Сообщение от тоже Анонимemail (ok), 30-Апр-25, 13:34   +/
> всего лишь следствие, что в cp/m файлы были всегда в верхнем регистре

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

> Ну и попробуй объяснить

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #330

344. Сообщение от Аноним (23), 30-Апр-25, 13:36    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #336 Ответы: #358

347. Сообщение от Аноним (347), 30-Апр-25, 14:27   +1 +/
Регистры нужны сугубо для человека, машине вообще поx, что ты там и как назовёшь.
Но по факту когда хуман ищет файл, ему ВСЁ РАВНО, какой там регистр! Он его не помнил никогда и не должен. Просто найди "фотки ДР 2005" - ЗАЧЕМ тут регистр?!?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

348. Сообщение от Аноним (-), 30-Апр-25, 15:00   +/
> Советую в следующий раз не лепить нелепый наброс на Микростфт,

А таки у меня к ним есть определенные претензии за то что они начали вот этот балаган с регистронезависимостью. И сейчас это все - приводит к пачке веселых CVE, имя которым легион. К счастью манера делать из маздая сервера вывешенные в интернет несколько поутихла, но оказались и другие способы, типа залить архивчик, или файло в git вообще подсунуть, и много чего еще. А теперь это булшит бинго зачем-то в линухе. Потому что поналезло тут всяких, типа вас, с маздайными замашками.

И как винду можно было в BSOD вынести заходом на страничку пытающуюся открыть что-то типа file://c:\con\con - я тоже не забыл. Я вообще злопамятный на такие подставы. И бсоды от открытия картинки отмасштабированной до 100000x100000 чтоли - помню. Секурити и онлайн безопасность винды всегда были образцом для подражания. Со знаком минус.

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

С вон теми замашками - сможет создать много чего еще интересного. При том не того что подразумевалось.

> А сейчас добавлю, что по причине недостатка знаний, и даже не буду уточнять номер RFC. ;)

Какой, нахрен, RFC по винде? В этом мире есть более 1 протокола взаимодействия, если что :). Вот вы поручитесь что будет с маздайцем если ему в каком-нибудь rsync или торенте - что-то этакое форсировано подсунуть?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #329

349. Сообщение от Аноним (349), 30-Апр-25, 15:10   +/
юникод превратили в какой-то бардак. цветные смайлики -- а дальше что? анимириванные 3д-смайлики с поддержкой дх12 и содержащие фреймы с джава-скриптом, выполняемым на ассемблере?

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

мне-то не жалко, просто поверхность атаки увеличилась на десятки порядков.
как будто специально превращают стандарты в решет0 (почему это слово не пропускает фильтр опеннета????), выполняющее функции медиа-центра для детей.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #364

350. Сообщение от freehck (ok), 30-Апр-25, 15:34   +/
> Ты совершенно не понимаешь в чем проблема с UB для целочисленных переполнений
> в С. А проблема в том, что умный компилятор без предупреждения
> выбрасывает код

Эм. Так ведь оптимизации компилятора не имеют никакого отношения к UB языка.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288

351. Сообщение от freehck (ok), 30-Апр-25, 15:41   +/
> Тут не с регистронезависимостью проблема, а с тем, что в именах файлов
> разрешена всякая дичь вроде вот этих юникодных сердечек.

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

А юникод развивается. И добавляет постоянно новые символы. Кто будет поддерживать список разрешённых символов в актуальном состоянии? Хотите взяться за такое дело?

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

Каждая проверка на предмет того, что файл содержит символы только из разрешённого списка -- будет жрать вычислительные ресурсы. Чем больше символов -- тем больше жрёт. И её надо производить для каждого файла? Железо должно работать, да?

В общем, это плохое решение. Куда легче -- поступить так, как предлагает Линус, и просто больше не делать функциональность регистронезависимости в ФС.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #386

352. Сообщение от Аноним (-), 30-Апр-25, 17:11   +/
> Ну и попробуй объяснить условному Васяну, что файл ДОКУМЕНТВАСИ.XLSX и документваси.xlsx
> как-то различаются. Ведь и ежу понятно, что это один и тот
> же файл. Ну и компы они не для яфинов, они для
> Васянов, поэтому у Микрософта всё и сделано правильно.

Но вебсервак то - сохранит и тот и другой, ибо не маздай голимый. И при случае отдаст Васе другой документ. После чего Вася как раз рискует внепланово переписать себе файло - НЕ ТЕМ документом.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #330 Ответы: #359

354. Сообщение от Аноним (288), 30-Апр-25, 17:47   +/
>Эм. Так ведь оптимизации компилятора не имеют никакого отношения к UB языка.

Имеют, непосредственное. Оптимизации применяются исходя из предположения, что в коде нет UB.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288

355. Сообщение от Аноним (355), 30-Апр-25, 18:48   +/
Не вижу приципиальной разницы между буквой, иероглифом и сердечком. И то, и другое, и третье имеет совершенно произвольное значение, определяемое культурой. Названия файлов для компьютера бессмысленны в любой кодировке с любым набором символов. Для человека же все эти закорючки имеют субъективное значение, и поскольку задача компьютера быть удобным инструментом, вводить произвольные ограничения на набор символов контрпродуктивно. По техническим причинам необходимы маркеры иерархии (разделители путей, возможно имена томов/дисков), но и только. Должен ли и этот маркер выбираться пользователем произвольно, или должен быть однозначно определён на уровне ФС — вопрос открытый, но не принципиальный. Я считаю полезной иметь возможность давать символам произвольные значения, а кому-то — как мы можем видеть по комментариям — и 8.3 непозволительная роскошь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222

356. Сообщение от ProfessorNavigator (ok), 30-Апр-25, 18:49   +/
> Это вы - живая иллюстрация. Антипаттернов в программировании. Живой пример как писать
> софт вообще совсем не надо. От юзабилити - до антибаг кодинга
> и ИБ! Можно выбрать любое направление - и не прогадать.
> Почему? Потому что достаточно посмотреть на ваш софт. Его скрины. Сорцы и
> вообще.

Да-да, чтоб вам поверили - главное кричать погромче)) И вообще - причём здесь я и мой софт? Я вроде бы в "крутые профессионалы" никогда не напрашивался. Так, умею кое-чего. А уж оценивать программу по скриншотам - это пять. Дальше можно и не продолжать в общем.

>[оверквотинг удален]
> взял бы асм. Там это по крайней мере - можно. А
> вот именно в сишке - вы даже долбаный флаг Carry посмотреть
> вот так по простому - не сможете. И получается максимально дурацкая
> ситуация. Даже просто определить - переполнится ли вот тут или нет
> в сишке это тот еще квест. Особенно с дефолтными типами. Какой
> процент програмеров успешно с ним справляется - вы поняли! И некоторые
> вещи не очень криво делаются - только левыми builtin которые не
> стандартные. Хотя можно еще превратить код в квест по брейнфаку и
> посмотреть сколько програмеров облажается в его понимании. Что так no-win, что
> так.

Что вы тут плач Ярославны разводите?)) Берите и пишите сами, чтоб не переполнялось. Сделать это достаточно просто. Или берите готовое - вон для вас библиотека gmp для длинной арифметики. Там вообще ничего не переполняется, главное чтобы памяти хватило. В общем в очередной раз подтверждается тезис: "Плохому танцору..." Далее по тексту.

> В этом месте до хрустиков дошло - обернуть ручку грабель поролоном наконец.
> Ага, так можно было!

"До хрустиков дошло")) Ещё раз, библиотеки для длинной арифметики существуют не в единственном числе и не один год (а то и на десятки лет счёт пошёл уже). Там в принципе переполнений не бывает. Но у всего есть цена. Как и в Расте, всё считается программно, а значит - медленнее, чем стандартные типы. Если же говорить в целом, то единственное "нововведение" Раста - это встроенный в компилятор статический анализатор кода. Всё. Нужно ли оно? Очевидно, что нет.

> Во первых можно поговорить как в сишке эти самые типы определены. И
> как это работает по дефолту. Int - это сколько? Переполнится он
> вот тут? А на другой платформе? Ответ на этот простой вопрос
> - знатнейший брейнфак. Особенно если еще и какие-то операции с числами
> делать. А с signed это вообще - минное поле.

Ещё раз, если вам нужны типы с чётко определённым размером - они есть. Берите и пользуйтесь. int нужен там, где не особо важно, какой это будет длины, главное - чтобы быстро. Если вы этого не понимаете, то вам не нужно браться за программирование. Или для начала почитать "умные" книги. Хотя, боюсь, тут уже бесполезно...

> Я никакому процессору вообще ничего не говорил делать. Это заявление применимо только
> к программированию на ассемблере. Сишку же я юзал как раз чтобы
> на ассемблере не програмить и не лезть в интимные детали конкретного
> процессора, получив ПОРТАБЕЛЬНЫЙ код.

Да-да, расскажите нам про вашу квалификацию ещё))

>[оверквотинг удален]
> До этого вы вообще даже так с ходу не знаете -
> какой у этой фигни получился вот тут тип.
> 3) В сях так то еще есть - препроцессор. И им порой
> рюхают в компилтайм разные вещи. Только он - не сишка. Но
> - математику тоже умеет. И даже сильно больше чем математику. Он
> "почти тюринг полный" и на нем можно делать весьма хитрые конструкции,
> прелесть которых в том что все это обсчитается компилтайм, и можно
> сочетать понятную двуногому запись с эффективностью в run time. Проблема в
> том что комитет тупарей вон то к вот этому совсем никак
> не применял. И про эти типы препроцессор ничего не знает.

"В огороде бузина, а в Киеве - дядька".

> У меня этих uint32_t имхо сильно больше чем у вас.

Лежу под столом)) Жги ещё, товарищ))

> И тем
> не менее, баги на вон том - лезут. У почти всех.
> Чисто статистически. И в очередной раз затыкая "int" underflow за дидом
> при неожиданных (какая неожиданность!) внешних данных - это может и надоесть.
> И захотеться - более радикального решения этой проблемы. Так и появился
> хруст...

Да и пускай себе)) Хотите - пользуйтесь. Главное - другим только не показывайте))

> Мне никто ни цента за это не платит. Я просто люблю качественный
> софт и не люблю глупые баги и вулны на ровном месте.
> Так что при всей симпатии к сишке - было бы глупо
> игнорить недостаки или даунплеить удачные решения откровенно за@#$ших уже проблем.

Да не вопрос)) Пользуйтесь С++ - там большинство "проблем" решено уже давным давно.

> Как я уже сказал - мой профит никак не зависит от коментов
> на опеннете. И хрустом я не пользуюсь. Но знаете, когда gccrs
> дойдет до кондиции - я подумаю на эту тему. Потому что
> инженерное решение задолбавших проблем - в частности пусть и ценой усложнения
> компилера - таки лучше чем в i++'й раз запрыгивать на те
> же грабли с пофигом комитета тупарей на мои (и вообще отраслевые)
> проблемы.

Забавно. В очередной раз удивляюсь: люди на что угодно готовы пойти, лишь бы С++ не учить))

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

Да не вопрос)) Но софт от этого не спасёт, потому что тоже людьми написан.

> При том что это, кажется, про вас... процессор ему там что-то делает.
> В сишке. Ога. Где в сишке абстракции чтобы состояние этого процессора
> вообще видеть? А, нигде? :)

И какое "состояние" вы там собрались смотреть?)) Ох, блин... В общем, попытка замаскироваться засчитана. На тех, кто "живой" код в глаза ни разу не видел даже подействует наверно. По остальному - не зачёт. Приходите на пересдачу))


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #341 Ответы: #379

357. Сообщение от Аноним (355), 30-Апр-25, 18:52   +/
Как ты решил, что регистров может быть только два? У «смузихлёбного» алфавита вполне может быть произвольно большое количество регистров, и в этой системе "❤" и "❤️" могут быть представлены как сердечко в «чёрном регистре» и «красном регистре».
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #255 Ответы: #362

358. Сообщение от ProfessorNavigator (ok), 30-Апр-25, 18:56   +/
> Нахско-дагестанская языковая семья

Ясно.

> а тотальное уничтожение нахско-дагестанской языковой семьи началось еще во времена аннексии
> Кавказа.

Вопрос сложный. РИ с одной стороны "тюрьмой народов" не зря называли. С другой... Все, существующие сегодня языки, со временем исчезнут. Это объективный процесс. По одной из двух причин - либо ввиду смерти носителей, либо из-за того, что человечество сольётся в единое целое. Т.е. будет один единый язык. Скорее всего некая смесь из ныне существующих. Каких и в какой пропорции - сказать сложно.  


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #344 Ответы: #361

359. Сообщение от Аноним (355), 30-Апр-25, 19:07   +/
> Но вебсервак то - сохранит и тот и другой, ибо не маздай голимый.

Что, даже IIS или, не дай бог, Apache на Windows Server? Бида-бида…

> После чего Вася как раз рискует внепланово переписать себе файло - НЕ ТЕМ документом.

Вася как раз ничем не рискует. «Маздай голимый» делали для людей, так что файлик успешно скачается как документваси (1).xlsx если там уже лежит ДОКУМЕНТВАСИ.XLSX. На ОС сделанных для удобства компьютера у Васи будет дилемма — какой же из двух документов тот, который ему нужен, и как их отличить друг от друга не открывая.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #352 Ответы: #380

360. Сообщение от Аноним (355), 30-Апр-25, 19:12   +/
Смотрим в «Tips for mathematical handwriting»:

Don’t slash the 0. The Greek letter phi has a vertical slash; the empty-set symbol has a slanted slash.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #367

361. Сообщение от Аноним (23), 30-Апр-25, 19:40    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #358

362. Сообщение от Аноним (23), 30-Апр-25, 19:42   +/
> Как ты решил, что регистров может быть только два?

Я и не решал, повторяю:

"""
с какого бодуна? разве не алфавит того или иного языка об этом должен говорить?
"""

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #357

363. Сообщение от Аноним (347), 30-Апр-25, 22:33   +/
Значит г____но это, а не комитет. Очевидно же, что почти половина кирилицы схожа с латиницей:
АВЕКМНОРСТУХ - это всё русские символы, которые МОЖНО заменить латинскими. Но никто это не сделал. Ну и накуль нужóн этот комитет, который "тщательно изучал историю"?? Изучал, да ни___я не изучил. В результате даже 16-битного юникода нехватило - полезли в 32-битный.

Я считаю, что в текущем виде юникод - это позорище ИТ. Так же как USB и x86.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273

364. Сообщение от Аноним (347), 30-Апр-25, 22:41   +/
Очевидно, что "кое-кто" напрямую заинтересован в "pεшεTε" на десктопах! Потому и допускают всякую дичь.
В почте всё же нужен какой-то rich текст, но строго в рамках типографии - а-ля bbcode. А жабоскрипты и прочую ересь банить нещадно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #349 Ответы: #368

365. Сообщение от Анонимemail (365), 30-Апр-25, 23:19   +/
С ext2 можно. А зачем что-то более сложное / журналируемое для раздела, который не перезаписывается или обновляется крайне редко.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

366. Сообщение от ага (?), 30-Апр-25, 23:39   +/
Так-то могли-бы просто форсировать ASCII для регистронезависимого режима и не мучать джопу
Ответить | Правка | Наверх | Cообщить модератору

367. Сообщение от YetAnotherOnanym (ok), 30-Апр-25, 23:45   +/
Нуу, это-то понятно, что когда в имени файла может быть Greek letter phi или empty-set symbol, то зачёркивать ноль уже бессмысленно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #360

368. Сообщение от Аноним (109), 01-Май-25, 00:55   +/
Изобретают новую седушку для велосипеда, как обычная седушка, но более эргономично обхватывающая твою зд**ницу.
С такой седушкой. Ты удивишься, как ты мог использовать просто седушку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #364

369. Сообщение от Анониссимус (?), 01-Май-25, 01:58   +/
> Тогда это должен быть хекс, вероятно.

Соглашусь.

> В IPv6 придумали, блин, сразу несколько причин. Увы и ах.

Адрес ipv6 очень длинный, причём зачастую состоит на половину из нулей. Это веская причина.

> Скажем для v6 сокращенная форма есть.

И эта форма простая и понятная; и для человека, и для парсера. Других форм нет. Стандартизёры явно учли ошибки прошлого.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224

370. Сообщение от Аноним (-), 01-Май-25, 05:40   +/
> Да не, иногда в шрифтах L выглядит как i, 0 как o, я про это.
> Меня нечего взламывать, я не криптовалютчик.

Это ты пока не взломан - не криптовалютчик. А вот если тебя взломать и поставить майнер - уже вполне.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

371. Сообщение от Аноним (371), 01-Май-25, 05:41   –1 +/
>Вам мало что значительная часть ПО от не латиницы в путях выпадает в осадок

Времён Windows 98? Потому что даже хрюшный софт уже на *W-функции (UCS-2) переведён.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #342

373. Сообщение от Аноним (245), 01-Май-25, 08:03   +/
какой еще подстрочник? каакя нотация ?
числа начинающиесь с 0 в Си соответственно во многих шелах интерпретируются как восьмиричные
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #291

374. Сообщение от Аноним (374), 01-Май-25, 09:21   +/
Линус никогда не сможет определять оборудование? А то Альт-11 понаставил Нвидии на 1,7 ГБ, а при удалении ея деинсталлирует Хромиум. Хотя тот и так был бы снесён.
Ответить | Правка | Наверх | Cообщить модератору

375. Сообщение от Аноним (375), 01-Май-25, 11:11   +/
Эдуард? А что из-под анонима?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #333

376. Сообщение от Аноним (376), 01-Май-25, 12:25   +/
Когда не было юникода, был бешеный спрос на десятки тысяч разных кодировок текста. Предлагаете вернуться в эпоху, когда к текстовому файлу нужно прилагать, в какой кодировке он сохранён, вместо того, чтобы разрешить кому угодно писать его/её избранный алфавит и всё бы замечательно отрендерилось?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

377. Сообщение от Аноним (376), 01-Май-25, 12:35    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #311

378. Сообщение от Молодой Смузихлёб (?), 01-Май-25, 13:31   +/
Ну я вот храню фотографии с именами типа "2024-03-01 12:54:12.jpg", и каждая вторая программа (кхем, Nextcloud) начинает преобразовывать по своим правилам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #312

379. Сообщение от Аноним (-), 01-Май-25, 18:41   +/
> Да-да, чтоб вам поверили - главное кричать погромче))

Это мое мнение, ибо не первый год в софтострое. ИМХО, вам стоило б умерить гордыню и трезво оценивать скиллы VS остальные.

> И вообще - причём здесь я и мой софт? Я вроде бы в "крутые профессионалы"
> никогда не напрашивался.

Тогда, имхо, следовало быть скромнее в толкании "ценного" мнения "как надо" и предъявах.

> Так, умею кое-чего.

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

> А уж оценивать программу по скриншотам - это пять.

По сценарию за кадром в этом месте угорают профессионалы софтостроя, минимально понимающие аспект project management или хоть азы UI/UX.

> Дальше можно и не продолжать в общем.

Это в ваших интересах, ибо в таком возрасте совершать детские ошибки человека не украшает. Если вы думали что никто не заметит - напрасно, минимально продвинутые прогармеры очень наблюдательные. Работа у них такая.

> Что вы тут плач Ярославны разводите?)) Берите и пишите сами, чтоб не
> переполнялось. Сделать это достаточно просто.

Вообще-то весьма зависит от.
1) Стандарты си определены очень фривольно, много места для грабель.
2) То что на практике ожидают програмеры часто не совпадает.
3) Идея упростить жизнь авторам компилеров и спекописателям ценой кучи багов - такая себе.
4) Людям свойственно ошибаться.

И вот тут было бы кстати если компилер подстраховал бы.

> Или берите готовое - вон для вас библиотека gmp для длинной арифметики.

1) Они overly generic, огроменные и здоровые и вероятно тормознее чем частная реализация.
2) По этой причине - удачи в микроконтроллер засунуть, например. Переписывать? Я не для того си юзал чтобы потом грабли асма И ТАМ собирать, сорян! Code reuse мое все, я не живу вечно.
3) Если кто-то например IO с этим делает, он от понимания структуры данных никуда не денется. Иначе это при удобном случае - сломается.

> Там вообще ничего не переполняется, главное чтобы памяти хватило.

Так переполнения нас долбают - в каком-нибудь


for (int i = UserSuppliedCrap1;  i < UserSuppliedCrap2; <somethng bogus>)
{
  something[i] = 10;
}

...в ЛУЧШЕМ случае - будет infinite loop, из-за "never true", особенно если какие-то вычисления. Или сразу референснут something[-10], даже поймать можно было. Но "int" подразумевает что -10 в переменной ОК. А то что ее как индекс юзанули... в си штатно нет такой аналитики. Хотя внутри компилер много чего знает и пруфает в целях оптимизации. Или например оно понятия не имеет размер something. Something[100] - валидно или нет?

И тем более никто не е... что int oveflow случится, VS что юзерь в UserSuppliedCrap1/ UserSuppliedCrap2 или математике по пути.

И куда вы тут - gmp? Мне вот просто интересно, как вы это запишете :). И знаете, если я буду GMP хреначить, да еще asan/ubsan влеплю - я так то и жабу или дотнет взять мог, с такий же производительностью и жором ресурсов.

> В общем в очередной раз подтверждается тезис:
> "Плохому танцору..." Далее по тексту.

Статистически - переломов костей у "танцоров" многовато. Я лично патчил несколько глупых int overrun за грандами, на кривых входных данных. А то они прямые - с эфира, сети или файла - никто и не обещал.

> "До хрустиков дошло")) Ещё раз, библиотеки для длинной арифметики существуют не в
> единственном числе и не один год

Проблема си не в длинной арифметике. А в арифметике int вообще и том что вокруг. Очень хреново задефайнено в стандарте. Вплоть до того что overflow signed int'а - вообще UB. Изначально из-за implementation defined формата хранения signet int, существовало минимум 2 варианта. В C23 попустило немного, оставили только two's complement. Но затребовать well defined behavior - не, таки их не хватило. Для unsigned оно при том well defined по моему "since forever", алгоритмика активно закладывается на врап, в целях оптимизации, чтобы явно и мануально не делать это.

А именно длинная математика интересна в основном тем что при желании IO этого куда-нибудь в портабельном виде все же придется определиться где LSB/MSB. И никакой gmp сам по себе этот аспект не решит в общем случае.

> у всего есть цена. Как и в Расте, всё считается программно,
> а значит - медленнее,

Прелесть хруста в том что как раз - проверок в рантайме нет, просто ряд "антибажных приемов", при том половина известны и продвинутым сишникам. По части проверок debug режим примерно как ubsan в си. Релиз - так же как и си забивает для скорости на трек целочисленных операций, чудес не бывает, чекать int overrun в рантайме не бесплатно :P. Это минимум conditional какой-то надо в код врезать, прям в алгоритм.

А боров чекер... знаете, в си вы видите указатель на некую аллокацию. Аллокацию юзают из 10 мест. Вопрос прост как дрова: можно free() здесь и сейчас на ЭТО? Или это еще 3 из 10 локациям которые это референсили - еще надо? Не угадаете - будут либо утечки памяти, либо - use after free. Боров довольно элегантно решает эту проблему, форся правильный usage таких вещей с проверяемостью КОМПИЛ ТАЙМ.

Почему бы не признать что при всей мерзотности синтаксиса хруста и вендорлокнутой экосистеме, некие рациональные зерна в дизайне есть? Продвинутые сишники часть могут делать препроцессором, анализаторами и проч. Свалив явно кривые потуги в фазе компила, специфичными компилтайм ассертами. Ибо фэйл в рантайме - это прекрасно, теперь представьте что фирмвар ECU вашего авто в assert на скорости 100+ так сделает. Все еще хочется assert в рантайме?

> чем стандартные типы.

Это не особо юзабельно в базовых конструкциях языка. Плюсы на что-то такое еще реально убедить. Из них и нечто типа хруста вылепить можно. Вот прям заоверлоадив энному типу operator [] и оно будет чекать валиден ли доступ. И даже нечто типа борова изобразить можно. На сях это не особо получится в нормальном виде.

> Если же говорить в целом, то единственное "нововведение" Раста - это встроенный
> в компилятор статический анализатор кода. Всё. Нужно ли оно? Очевидно, что нет.

И еще - для начала - антибажный дизайн и более удачные аннотации намерений програмера. Скажем в си все массивы - "decays to pointer" и аннотация вида void func(foo_t foo[10], bar_t bar[20]) радостно забьет на 10 и 20 и если ваш foo лишь [5] оно радостно промотается по 5 лишним элементам. Кстати лесится: void func(foo_t foo[static 10] ... - а вот так уже компилер буедет орать варнингом если foo_t foo[5] в такое попатыться. Можно еще радикальнее через struct, но - костыли же. При том у каждого свои.

> Ещё раз, если вам нужны типы с чётко определённым размером - они
> есть. Берите и пользуйтесь.

Теперь объясните это, допустим, препроцессору, которым я вон ту таблицу в компилтайме заполнял, чтоб не заполнять дофига полей лапками как обезьяна а ПОСЧИТАТЬ их в компилтайм? Комитет бакланов не хватило на то чтобы то счастье распостранить ВЕЗДЕ. И integer promotion там все равно норовит при случае "int" вкостылить.

...на память об этом не так уж много кода переживет -Wconversion (gcc/clang). А ваш код - переживает?

> int нужен там, где не особо важно, какой это будет длины, главное - чтобы быстро.

При этом дофига програмеров - жестко лажает с допущениями где это (не)ок. Даже гранды.

> Если вы этого не понимаете, то вам не нужно браться за программирование.

Я думаю что вы не поняли что дедушка Кнут сказал про "premature optimization is a root of all evil". Да-да, именно про такие фортели в 95% случаев.

А на данный момент компилер очень хорошо оптимизирует код. Более того. Вы явно не смотрели что LTO может сделать на именно уровне ASM. Вы бы сами до половины оптимизаций вообще не доперли бы. Ну то-есть на куске кода в килобайт может вы его и обставите. А сделайте это 20 кило кода - и он пожалуй обставит вас, ему не обломно трекать что 2 килобайта назад удобную константу уже вгрузили и можно скипнуть вот тут вгруз регистров. Удачи такое мануально.

> Или для начала почитать "умные" книги. Хотя, боюсь, тут уже бесполезно...

Я так то - читал. И учителя у меня норм были. А потом я посмотрел как это реально применяется и какие best practices устаканились. И сделал выводы.

> Да-да, расскажите нам про вашу квалификацию ещё))

Я уже рассказал выше что думаю о соотношении вашего скилла VS чсв и ценности этого мнения.

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

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

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

>> У меня этих uint32_t имхо сильно больше чем у вас.
> Лежу под столом)) Жги ещё, товарищ))

Нефиг бухать, тогда и под столом валяться не придется.

>> И захотеться - более радикального решения этой проблемы. Так и появился хруст...
> Да и пускай себе)) Хотите - пользуйтесь. Главное - другим только не показывайте))

ИМХО, когда научитесь делать нормальные юзеринтерфейсы и код писать так чтобы глаза не вытекали - тогда и приходите с "ценным" мнением. Так просто и банально.

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

>> игнорить недостаки или даунплеить удачные решения откровенно за@#$ших уже проблем.
> Да не вопрос)) Пользуйтесь С++ - там большинство "проблем" решено уже давным давно.

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

Тем не менее...
1) Аналог допустим borrow checking на си++ не есть стандартная фича. Я знаю проекты где нечто сравнимое сделали. Но это рвет мозг сторонним програмерам.
2) Часть вещей в C++ будет таки - в рантайме, с оверхедом.
3) Я даже не знаю кто из C++ и Rust победит в номинации "Brainfuck 2.0". Война была равна.
4) Что хуже всего - "int" и все его дурные грабли (и препроцессор) унаследованы от си.

Мое частное мнение - все эти "int" давно пора сделать well defined и все левые поползновения маркировать - unsafe. Чтобы точно знать где грабли. Ставят же таблички "осторожно, высокое напряжение".

> Забавно. В очередной раз удивляюсь: люди на что угодно готовы пойти, лишь
> бы С++ не учить))

Я его даже малость знаю - в объеме достаточном для прагматичного решения ряда моих задач, типа довольно круто пропатчить вон ту программу. Но он сложный. И кривой. И половина самой жесткой кривизны это как раз легаси от си. Типа позора с целочислеенными типами, и ровно те же факапы в препроцессоре.

Пожалуй хруст так то даже проще чем C++ в целом. У C++ дофига субстандартов и за годы там отросло немеряно фич. И ООП, на котором порой делают очень крутые и нестандартные абстракции.

> Да не вопрос)) Но софт от этого не спасёт, потому что тоже людьми написан.

Вообще-то из ненадежных компоенентов можно собрать более надежную чем каждый отдельный компонент - и это часть процесса. Вероятность того что облажается (компилер && человек) равна произведению вероятностей. Т.е. радикально ниже. Значит bug rate - убавится. Видите, законы природы можно использовать - себе во благо. Теорвер, например.

>> В сишке. Ога. Где в сишке абстракции чтобы состояние этого процессора
>> вообще видеть? А, нигде? :)
> И какое "состояние" вы там собрались смотреть?)) Ох, блин...

В случае математики и переполнений? Флаги процессора, типа carry там всякого. А вы что подумали? На асме такое делается 1-2 командами. Но в плотном цикле это скорость порушит очень даже, и если в каком-нибудь кодеке или крипто это воткнуть - и зачем нам "дотнет № 2"? А так чтобы избирательно проверить вот только тут? Не то чтобы СОВСЕМ нельзя, но... левые builtin для этого - вообще не стандартная сишка. А без этого - програминг больше брейнфак напоминать начинает и код - что угодно, но не элегантный, простой и понятный даже обезьяне. А без этого его и половина двуногих поймет - неверно.

> В общем, попытка замаскироваться засчитана.

Не, это немного не так. Вы просто не поняли мой пойнт. Поскольку ваш опыт в софтострое - без году неделя. Это по вам - видно. Зато ЧСВ у вас - не целый отдел крутой корпы хватит.

> На тех, кто "живой" код в глаза ни разу не видел даже подействует наверно.
> По остальному - не зачёт. Приходите на пересдачу))

Проблема в том что тут ученики и учителя местами перепутаны.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #356 Ответы: #384

380. Сообщение от Аноним (-), 01-Май-25, 19:31   –1 +/
> Что, даже IIS или, не дай бог, Apache на Windows Server? Бида-бида…

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

Достаточно сказать что маздайапдейт грузит апдейты - линуксным CDN. Это при том что у майкрософта датацентров - во, и лицензий уж себе то можно и выписать наверное. Но видимо маркетинговый булшит вместо эффективной, быстрой и дешевой сервировки файлов - не очень :)

>> После чего Вася как раз рискует внепланово переписать себе файло - НЕ ТЕМ документом.
> Вася как раз ничем не рискует. «Маздай голимый» делали для людей, так
> что файлик успешно скачается как документваси (1).xlsx

Вот это - очень зависит от того кто, что какой протокол, чем качалось, ...

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

> если там уже лежит ДОКУМЕНТВАСИ.XLSX. На ОС сделанных для удобства компьютера
> у Васи будет дилемма — какой же из двух документов тот, который ему нужен, и
> как их отличить друг от друга не открывая.

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

Классическое такое - "хотели как лучше, а пооучилось как всегда".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #359

381. Сообщение от Аноним (-), 01-Май-25, 19:36   +/
> А можно было сделать проще, у файла два атрибута номер и текстовое
> поле, система оперирует именами, а текстовое поле это та фигня, что
> отображается пользователю и в принципе не важно, что там записано и
> каким регистром.

Почему-то желающих оперировать номерами inode - не сильно дофига оказалось...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208

383. Сообщение от Dmityry (?), 01-Май-25, 21:05   +1 +/
Это не национальный, это женский алфавит. На нем девочки пишут, а ты тут со своей программистской логикой лезешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

384. Сообщение от ProfessorNavigator (ok), 01-Май-25, 21:16   +/
> Это мое мнение, ибо не первый год в софтострое. ИМХО, вам стоило
> б умерить гордыню и трезво оценивать скиллы VS остальные.

Какую гордыню? Я вам про вполне конкретные вещи говорю, а вы мне про скриншоты, ага.

> Тогда, имхо, следовало быть скромнее в толкании "ценного" мнения "как надо" и
> предъявах.

А чем моё мнение хуже любого другого? Вы пока что ничего конкретного в поддержку своей точки зрения не привели. Только выкрики.

> Вот исходя из реалий и прикидывайте ценность вашего мнения. Я эти реалии
> вижу не хуже вас.

Прикинул, дальше - что?

> По сценарию за кадром в этом месте угорают профессионалы софтостроя, минимально понимающие
> аспект project management или хоть азы UI/UX.

Да-да, жгите дальше))

> Это в ваших интересах, ибо в таком возрасте совершать детские ошибки человека
> не украшает. Если вы думали что никто не заметит - напрасно,
> минимально продвинутые прогармеры очень наблюдательные. Работа у них такая.

Чего?)) Вы о чём вообще?))

> Вообще-то весьма зависит от.
> 1) Стандарты си определены очень фривольно, много места для грабель.

Для сидящих в танке в танке повторяю ещё раз через дуло: стандарты такие, какие они есть, потому что аппаратная часть именно так работает. Дальше, вы хоть на голове стойте, но процессор у вас переполнение целочисленного типа посчитает именно так, как в него заложили это разработчики. И положит результат в соответствующую целочисленную переменную С/С++. Или любого другого ЯП, если в нём реализованы соответствующие типы. Поэтому в С/С++ если а + b > <max_type_value>, то undefined behavior. Обойти это можно программно, но считать в таком случае процессор будет дольше. Потому что сколько-то тактов понадобится на обработку соответствующей логики.  
  
> 2) То что на практике ожидают програмеры часто не совпадает.

Вообще плевать, кто там и чего ожидает. Читайте стандарты, там всё чётко прописано. Дополнительно - читайте документацию к компиляторам. Потому что - да. Реализация в компиляторе может не совпадать с соответствующим стандартом. Вон в clang до сих пор некоторые вещи из стандарта с++17 не реализованы (если код собирать именно с опцией c++17). Несмотря на то, что год на дворе в общем-то 2025.

> 3) Идея упростить жизнь авторам компилеров и спекописателям ценой кучи багов -
> такая себе.

Никто ничего никому не упрощал. См. ответ на п.1.

> 4) Людям свойственно ошибаться.
> И вот тут было бы кстати если компилер подстраховал бы.

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

> 1) Они overly generic, огроменные и здоровые и вероятно тормознее чем частная
> реализация.

Ага, зато в Расте оно лучше реализовано. Верим!

> 2) По этой причине - удачи в микроконтроллер засунуть, например. Переписывать? Я
> не для того си юзал чтобы потом грабли асма И ТАМ
> собирать, сорян! Code reuse мое все, я не живу вечно.

Ага, зато Растовый код где вообще ВСЕ переменные такие, вы туда засунете. Ну-ну.

> 3) Если кто-то например IO с этим делает, он от понимания структуры
> данных никуда не денется. Иначе это при удобном случае - сломается.

А это тут вообще причём?

>[оверквотинг удален]
> for (int i = UserSuppliedCrap1;  i < UserSuppliedCrap2; <somethng bogus>)
> {
>   something[i] = 10;
> }
> ...в ЛУЧШЕМ случае - будет infinite loop, из-за "never true", особенно если
> какие-то вычисления. Или сразу референснут something[-10], даже поймать можно было. Но
> "int" подразумевает что -10 в переменной ОК. А то что ее
> как индекс юзанули... в си штатно нет такой аналитики. Хотя внутри
> компилер много чего знает и пруфает в целях оптимизации. Или например
> оно понятия не имеет размер something. Something[100] - валидно или нет?

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

> И тем более никто не е... что int oveflow случится, VS что
> юзерь в UserSuppliedCrap1/ UserSuppliedCrap2 или математике по пути.

Все претензии - к производителям процессоров.

> И куда вы тут - gmp? Мне вот просто интересно, как вы
> это запишете :). И знаете, если я буду GMP хреначить, да
> еще asan/ubsan влеплю - я так то и жабу или дотнет
> взять мог, с такий же производительностью и жором ресурсов.

Куда-куда... На Кудыкину гору. Для начала, я на чистом С не пишу и не планирую (хотя и в нём это делается без проблем - читайте документацию по gmp). А в С++ это делается о-очень сложно. Представьте, как нужно перетрудиться, чтобы написать...
for(mpz_class i = 0; i < UpperBound; i++).

> Статистически - переломов костей у "танцоров" многовато. Я лично патчил несколько глупых
> int overrun за грандами, на кривых входных данных. А то они
> прямые - с эфира, сети или файла - никто и не
> обещал.

Сомневаюсь я, что вы хоть что-то патчили хоть раз. Если только в своём воображении.

> Проблема си не в длинной арифметике. А в арифметике int вообще и
> том что вокруг. Очень хреново задефайнено в стандарте. Вплоть до того
> что overflow signed int'а - вообще UB. Изначально из-за implementation defined
> формата хранения signet int, существовало минимум 2 варианта. В C23 попустило
> немного, оставили только two's complement. Но затребовать well defined behavior -
> не, таки их не хватило. Для unsigned оно при том well
> defined по моему "since forever", алгоритмика активно закладывается на врап, в
> целях оптимизации, чтобы явно и мануально не делать это.

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

> Прелесть хруста в том что как раз - проверок в рантайме нет,
> просто ряд "антибажных приемов", при том половина известны и продвинутым сишникам.
> По части проверок debug режим примерно как ubsan в си. Релиз
> - так же как и си забивает для скорости на трек
> целочисленных операций, чудес не бывает, чекать int overrun в рантайме не
> бесплатно :P. Это минимум conditional какой-то надо в код врезать, прям
> в алгоритм.

А при чём тут какие-то проверки? Это раз. А два, если вы про проверки переполнения целочисленного типа, то они есть. Потому что во время компиляции вы никогда не угадаете, какие числа будут обрабатываться. Если не умеете предсказывать будущее. Можно лишь примерно сказать, что вот здесь за пределы uint64_t не выйдем, потому что нет оперативной памяти такого размера в природе. И всё в таком роде.

> А боров чекер... знаете, в си вы видите указатель на некую аллокацию.
> Аллокацию юзают из 10 мест. Вопрос прост как дрова: можно free()
> здесь и сейчас на ЭТО? Или это еще 3 из 10
> локациям которые это референсили - еще надо? Не угадаете - будут
> либо утечки памяти, либо - use after free. Боров довольно элегантно
> решает эту проблему, форся правильный usage таких вещей с проверяемостью КОМПИЛ
> ТАЙМ.

Дальше - ваш borrow checker ошибается, и всё. Вы в пролёте, потому что полагаясь на него, сами вы ничего не проверяли. А borrow checker ошибётся гарантировано. И знаете, почему я так в этом уверен? Попробуйте на досуге вызвать SEGFAULT в компиляторе gcc, который вылизывают десятилетиями. Впрочем, у вас вряд ли получится. А мне удалось. На компиляции корректного кода.

> Почему бы не признать что при всей мерзотности синтаксиса хруста и вендорлокнутой
> экосистеме, некие рациональные зерна в дизайне есть? Продвинутые сишники часть могут
> делать препроцессором, анализаторами и проч. Свалив явно кривые потуги в фазе
> компила, специфичными компилтайм ассертами. Ибо фэйл в рантайме - это прекрасно,
> теперь представьте что фирмвар ECU вашего авто в assert на скорости
> 100+ так сделает. Все еще хочется assert в рантайме?

Да я уже не раз признавал)) Ещё раз - вся заслуга Ржавых (погремуха то зато какая красивая, прям загляденье) в том, что они статический анализатор кода засунули в компилятор. Всё. Достижение сомнительное, но пусть будет. А сомнительное оно потому, что городить из-за этого целый новый ЯП - абсолютно точно не нужно. Ну а дальше начинаем смотреть, кто, как и для какой цели использует Раст. Контингент программистов - мягко говоря, с сомнительной квалификацией. Это раз. Лицензии почти всего, что на нём написано, коротко можно охарактеризовать как "покорми корпорации, а то упыри голодные". Сплошь и рядом - одна пермиссивщина. Это два. Агрессивный маркетинг - это три. И банальная логика - это четыре. Логика в том, что если С на что-то и менять, то на С++. Потому что это два совместимых и очень похожих ЯП. Вплоть до того, что современные компиляторы С почти все на С++ написаны. С++ стандартизирован давным-давно к тому же. И с помощью него можно сделать вообще всё то же, что и на Ржавом. И даже больше. Потому что на С++ написано куча библиотек. Плюс накоплен громадный опыт использования где угодно и для чего угодно. При этом оно будет быстрее работать, а с точки зрения кода - куда более читабельно.

> Это не особо юзабельно в базовых конструкциях языка. Плюсы на что-то такое
> еще реально убедить. Из них и нечто типа хруста вылепить можно.
> Вот прям заоверлоадив энному типу operator [] и оно будет чекать
> валиден ли доступ. И даже нечто типа борова изобразить можно. На
> сях это не особо получится в нормальном виде.

Да. А ещё в С++ есть нормальное ООП, нормальная реализация многопоточности (да ещё и не в одном варианте).

> И еще - для начала - антибажный дизайн и более удачные аннотации
> намерений програмера. Скажем в си все массивы - "decays to pointer"
> и аннотация вида void func(foo_t foo[10], bar_t bar[20]) радостно забьет на
> 10 и 20 и если ваш foo лишь [5] оно радостно
> промотается по 5 лишним элементам. Кстати лесится: void func(foo_t foo[static 10]
> ... - а вот так уже компилер буедет орать варнингом если
> foo_t foo[5] в такое попатыться. Можно еще радикальнее через struct, но
> - костыли же. При том у каждого свои.

А оно так и должно быть. Потому что ЯП достаточно низкоуровневый. И это, что называется, "не баг, а фича". Причём, без шуток. Оно так и задумывалось.

> Теперь объясните это, допустим, препроцессору, которым я вон ту таблицу в компилтайме
> заполнял, чтоб не заполнять дофига полей лапками как обезьяна а ПОСЧИТАТЬ
> их в компилтайм? Комитет бакланов не хватило на то чтобы то
> счастье распостранить ВЕЗДЕ. И integer promotion там все равно норовит при
> случае "int" вкостылить.

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

> ...на память об этом не так уж много кода переживет -Wconversion (gcc/clang).
> А ваш код - переживает?

Да. Потому что я его на сборку проверяю обоими компиляторами обычно. И не на одной архитектуре.

> При этом дофига програмеров - жестко лажает с допущениями где это (не)ок.
> Даже гранды.

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

> Я думаю что вы не поняли что дедушка Кнут сказал про "premature
> optimization is a root of all evil". Да-да, именно про такие
> фортели в 95% случаев.

Честно? Мне плевать на всех дедушек вместе взятых с высокой колокольни. Авторитет не имеет никакого значения.

> А на данный момент компилер очень хорошо оптимизирует код. Более того. Вы
> явно не смотрели что LTO может сделать на именно уровне ASM.
> Вы бы сами до половины оптимизаций вообще не доперли бы. Ну
> то-есть на куске кода в килобайт может вы его и обставите.
> А сделайте это 20 кило кода - и он пожалуй обставит
> вас, ему не обломно трекать что 2 килобайта назад удобную константу
> уже вгрузили и можно скипнуть вот тут вгруз регистров. Удачи такое
> мануально.

Это вообще тут при чём?

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

Как вы что-то проверите, если результат вычислений заранее неизвестен? Если все вычисления ради того и затевались, чтобы получить результат?

> Нефиг бухать, тогда и под столом валяться не придется.

Да с такими комментариями оно и не нужно - и так весело)) Ох-хо-хо...

> ИМХО, когда научитесь делать нормальные юзеринтерфейсы и код писать так чтобы глаза
> не вытекали - тогда и приходите с "ценным" мнением. Так просто
> и банально.

К вам приходить?)) Спасибо, обойдусь.

> Я вообще хрустиков не жалую. Но признаю что мне бы хотелось некоторых
> фич из того что умеет хруст. Потому что в итоге я
> для себя часть этого переизобрел сам. Но изобретать нестандартный вел с
> необычными запчастями - хуже чем когда это 1 раз сделают нормально
> на всю толпу и доведут до ума (с этим у хрустиков
> пока проблемы, см отповедь в линухкернеле на тему скачайтеночнушку).

У них не "пока", у них в принципе проблемы. По-другому и быть не может.

> Вы даже близко не представляете себе какой код на плюсах я ухитрялся
> патчить. И что они там делали.

До-о... Верю!

> Тем не менее...
> 1) Аналог допустим borrow checking на си++ не есть стандартная фича. Я
> знаю проекты где нечто сравнимое сделали. Но это рвет мозг сторонним
> програмерам.
> 2) Часть вещей в C++ будет таки - в рантайме, с оверхедом.

Да и пускай себе.

> 3) Я даже не знаю кто из C++ и Rust победит в
> номинации "Brainfuck 2.0". Война была равна.
> 4) Что хуже всего - "int" и все его дурные грабли (и
> препроцессор) унаследованы от си.

Нет там никаких граблей, есть лишь "программисты", которые не умеют читать документацию.

> Мое частное мнение - все эти "int" давно пора сделать well defined
> и все левые поползновения маркировать - unsafe. Чтобы точно знать где
> грабли. Ставят же таблички "осторожно, высокое напряжение".

Оно и так всем, кроме вас, известно))

> Я его даже малость знаю - в объеме достаточном для прагматичного решения
> ряда моих задач, типа довольно круто пропатчить вон ту программу. Но
> он сложный. И кривой. И половина самой жесткой кривизны это как
> раз легаси от си. Типа позора с целочислеенными типами, и ровно
> те же факапы в препроцессоре.

До-о... В очередной раз слышу про "кривость" С++... От тех, кто его не осилил))

> Пожалуй хруст так то даже проще чем C++ в целом. У C++
> дофига субстандартов и за годы там отросло немеряно фич. И ООП,
> на котором порой делают очень крутые и нестандартные абстракции.

Во-от... Так и скажите: "Я не осилил". Громко и чётко. Прежде всего - себе самому. Признание проблемы - первый шаг к её решению.

> Вообще-то из ненадежных компоенентов можно собрать более надежную чем каждый отдельный
> компонент - и это часть процесса. Вероятность того что облажается (компилер
> && человек) равна произведению вероятностей. Т.е. радикально ниже. Значит bug rate
> - убавится. Видите, законы природы можно использовать - себе во благо.
> Теорвер, например.

Не-а, вероятности то как раз складываются. Только не впрямую. Математику писать лень - сами разберётесь. Более того, как уже сказал, вы будете полагаться на автоматику там, где этого делать не следует. И вместо нескольких мелких, некритических ошибок, получите по итогу одну, но такую, что прям epic fail.

> Не, это немного не так. Вы просто не поняли мой пойнт. Поскольку
> ваш опыт в софтострое - без году неделя. Это по вам
> - видно. Зато ЧСВ у вас - не целый отдел крутой
> корпы хватит.

Хы))

> Проблема в том что тут ученики и учителя местами перепутаны.

И с чувством юмора беда, да.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #379 Ответы: #390

385. Сообщение от wyry (ok), 01-Май-25, 23:08   +1 +/
Собственно чем больше Линус делится своим мышлением, тем больше понятно, почему Linux такой кривой по итогу.
По поводу файловых систем главный вопрос: для кого они существуют? Если для компа - ему до лампочки как называть фрагменты данных (ему также наплевать на каталоги и любые иные искусственные структуры). Если же мы сходимся на том, что файловые системы существуют больше для человека, то регистронезависимость - это важная тема, т.к. человеку значительно проще ориентироваться на то, когда файлы имеют объективно разные наименования. Более того, по хорошему следует на базовом уровне "запретить" неадекватные наименования и любые спец. символы в противовес тому, чтобы тащить за собой весь юникод, который уже превратился в абсолютный мусор.
Регистрозависимость - это простейшее решение, т.к. оно вообще не требует ровно никаких усилий для реализации. Собственно этим и Linux славится: никакого стабильного ABI, полный маразм в подключаемых библиотеках с одинаковыми именами функций (Порядок загрузки библиотек может влиять на то, какая версия символа будет использована) и прочие радости жизни.
Даже стабильные драйверы не написать, т.к. они имеют офигенный шанс сломаться при обновлении ядра. Зато с "умным" видом рассуждаем на тему регистров в файловых системах, чтобы загадить индустрию окончательно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #387, #394

386. Сообщение от Дима (??), 02-Май-25, 13:08   +/
в именах файлов можно ограничиться английским алфавитом, малыми буквам, проблем-то
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #351 Ответы: #389

387. Сообщение от Аноним (-), 02-Май-25, 13:25   +/
>Собственно чем больше Линус делится своим мышлением, тем больше понятно, почему Linux такой кривой по итогу.

Линукс оптимален. Чо ты нагнетаешь?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #385

388. Сообщение от Илья (??), 02-Май-25, 13:43   +/
>>А есть хотя бы одна причина использовать какие-то числа кроме ОБЫЧНЫХ ?
> hex-редакторы придумали и применяются не зря. Там используется hex-нотация, потому что удобно.

А знаешь, что ещё удобно? Когда не нужно открывать хекс редактор.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #289

389. Сообщение от freehck (ok), 02-Май-25, 16:49   +/
> в именах файлов можно ограничиться английским алфавитом, малыми буквам, проблем-то

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #386

390. Сообщение от Аноним (390), 02-Май-25, 19:20   +/
> Какую гордыню? Я вам про вполне конкретные вещи говорю,

В смысле, конкретно обсудили мою персоналию и попытались троллить? Столь же удачно как и с UI и с кодом, имхо, получилось.

> а вы мне про скриншоты, ага.

Люблю возвращать фавор в симметричном формате, так таким как вы - понятнее.

> А чем моё мнение хуже любого другого?

Тем что ваше соотношение апломба и компетентности ни к черту. Это как если бы Фукс, эксперт по картам (игральным) с чего-то стал учить вас навигации.

> Прикинул, дальше - что?

Догадайтесь сами.

> Да-да, жгите дальше))

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

...
>> 1) Стандарты си определены очень фривольно, много места для грабель.
> Для сидящих в танке в танке повторяю ещё раз через дуло: стандарты
> такие, какие они есть, потому что аппаратная часть именно так работает.

Какая именно "аппаратная часть" так работает? Нельзя ли уточнить, в деталях?

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

Очень интересно. А почему для signed int переполнение UB, а для unsigned - вполне себе well defined: для unsigned стандартом явно требуется конкретное поведение, с врапом, и всем пофиг как вы там реализуете это.

Раз вы решили поумничать на тему - вот и раскажите чем signed и unsigned так принципиально, отличаются что дискриминация. Я то в отличие от вас догадываюсь, и подсказал немного. Но теперь ваша очередь. Попробуйте отдуться за свой апломб.

> И положит результат в соответствующую целочисленную переменную С/С++.

Простите, знаковую или беззнаковую? ;) А то это 2 довольно разных случая. Что тупо, но - это же си. Так что можно сделать well defined для одного и ub для второго.

> Или любого другого ЯП, если в нём реализованы соответствующие типы.

У любых других ЯП могут быть очень сильно свои идеи как и что.

> Поэтому в С/С++ если а + b > <max_type_value>, то undefined behavior.

То-есть стандарты вы не читали. И тем более - не видели код типа крипто, совершенно рутинно ЭТО делающий. Для unsigned, конечно, где это - специфицировано, и всем пофиг как проц и кто там сделает.

Итого: я вас поймал. Вы стандарт не читали, но задвинули мне отсебятины. Знаете в чем наше отличие? Я таки - удосужился стандарт еще и почитать, и поотвисать с теми кто мне может на эту тему реальный мастеркласс дать. После этого - а вы точно хотите об этом поговорить? Именно со мной? Будучи уверенными что вы лучше меня знаете топик? Тогда вот вам!

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

Спасибо капитан очевидность. И тем не менее. В gcc например есть нечто типа -ffast-math, чтоли, для убер-оптимизаций, если багодром пофигу. Но оно noncompliant как раз.

> Вообще плевать, кто там и чего ожидает.

А мне не плевать - на то что в результате дохрена багов и CVE на ровном месте. И я буду считать что это плохой стандарт. Имея на руках обоснования в виде CVE.

> Читайте стандарты, там всё чётко прописано.

Вы их сами - не читали. И я вас на именно этом и поймал. Ибо вы явно не в курсе что там UB только для signed, а для unsigned - well defined. С пофигом что там в каком железе, внезапно.

Более того, иногда железо вообще не совсем compliant. Скажем AVR весьма криво выглядит в си, и если попытаться там арифметику с указателями... окажется что указатели у гарвардца бывают разные, и ...

> Дополнительно - читайте документацию к компиляторам. Потому что - да.

Это не лишне. Но вы кажется не поняли что си настолько клевый стандарт что там враппинг well defined для unsigned, но ub для signed. Почему так? А ктулху его знает. Так привыкли.

Да что там. Посмотрим как определен "char". Он знаковый или беззнаковый по дефолту? А, погодите, и запись int i = 10 тоже даже не гарантирует signed оно или unsigned? Офигенный стандарт - чтобы прострелить пятку. Откуда следует что вон тот ваш совет - не катит. Сюрприз!

> Реализация в компиляторе может не совпадать с соответствующим стандартом.

Тогда это по большому счету - баг компилятора.

> Вон в clang до сих пор некоторые вещи из стандарта с++17 не реализованы
> (если код собирать именно с опцией c++17). Несмотря на то, что
> год на дворе в общем-то 2025.

Да там и в GCC только недавно некоторые вещи сделали. Вот, #embed из C23 наконец завезли. Но сейчас то 2025 уже.

> Никто ничего никому не упрощал. См. ответ на п.1.

Именно что упростили. Сделав слишком дофига всего - опциональным или poorly defined. Можно начать с знаковости "char" без квалификаторов, допустим. Отличный способ сделать себе день^W мозг. А, в GCC даже ключи есть меняющие дефолт? Классно, да? :)

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

У вас шнурки развязались, профессор.

> Ага, зато в Расте оно лучше реализовано. Верим!

При чем тут это? В расте антибаг лучше реализован. Боров, сразу нормальные типы без идиотских рулезов промоушна и прочих типичных грабель. Из "big" типов вспоминается uint128 но он так то и в сях как GCC extension - есть. Правда не везде.

> Ага, зато Растовый код где вообще ВСЕ переменные такие, вы туда засунете.
> Ну-ну.

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

>> 3) Если кто-то например IO с этим делает, он от понимания структуры
>> данных никуда не денется. Иначе это при удобном случае - сломается.
> А это тут вообще причём?

При том что тут представление в памяти и в файле/проводе и все договоренности придется состыковать. Сюрприз!

> Ага, а до size_t мы не дочитали, так что его тоже не существует.

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

> слазьте - обсуждали переполнение целочисленных типов вроде бы, а не выходы
> за границы массивов.

Внезапно, одно порой ведет к другому. Представляете, out of bounds бывает следствием факапа в математике с переменной индекса! Я лично такое фиксил за грандом. Он на определенных входных данных в "int" уходил в минуса, и ... :)

> вижу - закончится очередной демонстрацией вашей особо высокой квалификации.

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

> Все претензии - к производителям процессоров.

Не, вот извините. Я не программирую под конкретный процессор. Я программирую под конкретный стандарт си. И поэтому претензии буду выдвигать - хреновым стандартам. Как требования стандарта натянуты на конкретный проц - мне не интеремно, это проблемы авторов компилера. А вот мне интересно чтобы стандарт не клал грабли на ровном месте.

>> И знаете, если я буду GMP хреначить, да еще asan/ubsan влеплю - я так то и жабу или дотнет
>> взять мог, с такий же производительностью и жором ресурсов.
> Куда-куда... На Кудыкину гору. Для начала, я на чистом С не пишу и не планирую

А я пишу. И планирую. Хотя и гнутыми экстеншнами балуюсь. Часть из них в C23 наконец затолкали. Но и там - полумеры и костыли.

> (хотя и в нём это делается без проблем - читайте документацию по gmp).

Да нафиг мне ваш gmp вперся, по большому счету. Я и сам могу написать широкую математику. Понимая все аспекты. Я это проверял несколько раз для частных случаев, и с пониманием вон тез аспектов. Без этого понимания я б вообще в дискуссию не полез.

> А в С++ это делается о-очень сложно. Представьте, как нужно перетрудиться, чтобы написать...
> for(mpz_class i = 0; i < UpperBound; i++).

Там этот класс надо - написать для начала. И если делать не совсем ректально то даже и < UpperBound не потребуется. Будет или итератор какой, или еше какой safe доступ. Который таки облажаеться не сможет/не даст. Но это все придется вкостыливать именно самому в общем случае.

> Сомневаюсь я, что вы хоть что-то патчили хоть раз. Если только в своём воображении.

Ага, и вон те роли в опенсорсных проектах мне приснились. Чойта они меня ревьюером кода взяли? Сам не понимаю. Надо было эксперта типа вас же. А что, много желающих вас ревьюером зазвать?

> Слушайте, из-за того, что вы бредятину повторите в двадцатый раз по кругу,
> она во что-то осмысленное не превратиться. Если нужны целочисленные переменные с
> фиксированным размером - используйте их. Если есть вероятность переполнения - библиотеку
> gmp. Всё, точка. На этом вопрос закрыт.

Не, вот извините. Вы стандарты не читали и жесточайше спалились. Ибо не знаете что для unsigned переполнение - well defined, и на это можно уповать.

Конкретный пример? А вон в вике крипто, salsa/chacha попсовые. И вот прям там оно уповает на врап для uint32_t. Стандартный трюк для крипто и компилер ОБЯЗАН обеспечить это поведение. Иначе он - noncompliant. Видите, а стандарты то читать - полезно. Потом всякие очковтирателей можно в пень слать.

> А при чём тут какие-то проверки? Это раз.

При том что overflow например поймать. Это надо carry флаг чекнуть, лишние инструкции в общем случае.

> А два, если вы про проверки переполнения целочисленного типа, то они есть. Потому что во
> время компиляции вы никогда не угадаете, какие числа будут обрабатываться.

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

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

Прикиньте, оно на раз может заметить что функция может получать на вход только 1, 2 и 10 и отпедалить пруф что вот тут проверку можно - удалить. И убрать ее нахрен. Правда, потом Торвальдс вон там кроет когда ему проверку null чрезмерно ретиво снесли :)

> Если не умеете предсказывать будущее. Можно лишь примерно сказать, что вот здесь
> за пределы uint64_t не выйдем,

Вообще-то...
1) Я умею предсказывать будущее. Просто не всегда и не всегда на 100% точно.
2) А вот таки по ширине математики я обычно могу сказать ТОЧНО какие у меня максимально возможные значения. Чтобы не быть как вон те, с CVE, да и вообще, в фирмварях видите ли вредно так лажаться - потом какие-нибудь силовые ключи бахают и проч.

> потому что нет оперативной памяти такого размера в природе. И всё в таком роде.

Вообще-то если я допустим жую 32 отсчета с 12-bit ADC я таки могу весьма конкретно уповать что их сумма лезет в u32.

>> решает эту проблему, форся правильный usage таких вещей с проверяемостью КОМПИЛ ТАЙМ.
> Дальше - ваш borrow checker ошибается, и всё. Вы в пролёте, потому
> что полагаясь на него, сами вы ничего не проверяли.

Там и еще веселее приколы есть. Вплоть до try_* всякие. Но си как таковые не решают эту проблему - никак! Да и плюсы - лишь местами. Это ведет к дофига багов.

> Впрочем, у вас вряд ли получится. А мне удалось. На компиляции корректного кода.

Надо же, в программах бывают баги.

> Да я уже не раз признавал)) Ещё раз - вся заслуга Ржавых
> (погремуха то зато какая красивая, прям загляденье) в том, что они
> статический анализатор кода засунули в компилятор. Всё.

Проблема C в том что он вообще местами статическому анализу не особо поддается. Пример с [] decays to pointer я приводил. Не менее интересно void* анализировать.

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

> будет. А сомнительное оно потому, что городить из-за этого целый новый
> ЯП - абсолютно точно не нужно.

В сях и плюсах по наследству некоторые проблемы с статическим анализом особо не лечатся, стандарты так сделаны и фичи языка такие. Аннотации намерений кодера - в вещах типа void* просто отсутствуют.

> в том, что если С на что-то и менять, то на
> С++. Потому что это два совместимых и очень похожих ЯП.

Совместимы и похожи они не на 100%, а за какой-нибудь reinterpret_cast хочется кого-нибудь вообще прибить нахрен.

...
> С++ стандартизирован давным-давно к тому же. И с помощью него можно
> сделать вообще всё то же, что и на Ржавом.

Я даже аналоги борова видел. Но типовой C++'ер поделит на ноль с такого.

> будет быстрее работать, а с точки зрения кода - куда более читабельно.

На мой вкус C++ и Rust могут порубиться за звание Brainfuck-2.0. Простоту и элегантность си продолбали оба.

...
> Да. А ещё в С++ есть нормальное ООП, нормальная реализация многопоточности (да
> ещё и не в одном варианте).

Ну тут за нормальное с вами могут поспорить. Да и спорный вопрос - баг оно или фича.

> А оно так и должно быть. Потому что ЯП достаточно низкоуровневый.

Не, вот на минуточку. Я дал ВСЕ АННОТАЦИИ НАМЕРЕНИЙ и то что стандарт не затребовал верификацию при их наличии - это факап стандарта. ЧСХ для "static N" работает же по факту! Это не error но варнингами орет шикарно. И таки - вот - видит что буфер мелкий.

Внутрях компилер еще и не такое видит. Но в силу педальности стандарта - интерфейса к этому нет.

> И это, что называется, "не баг, а фича". Причём, без шуток. Оно
> так и задумывалось.

Внезапнй прострел пяток не является фичой. И при вон тех аннотациях можно математически пруфануть (не)корректность. И это даже работает. Частично! :E

> В сто тридцать первый раз - используйте типы фиксированной длины.

Расскажите как это сделать допустим в препроцессоре? А, погодите, он вообще типы не рюхает? :)

> Если вы вкорячили int туда, где требуется точный размер целочисленного типа - вы
> сам себе злобный буратино.

Этих мест намного больше чем большая часть програмеров типа вас думали.

>> ...на память об этом не так уж много кода переживет -Wconversion (gcc/clang).
>> А ваш код - переживает?
> Да. Потому что я его на сборку проверяю обоими компиляторами обычно. И
> не на одной архитектуре.

У gcc и clang у обоих есть -Wconversion но это специфичный свич, прозванивающий все что касается промошна, конверсий и потенциальных факапов. Только он не врублен по дефолту ибо большая часть сишного кода при этом сыпет дофига варнингов.

> Во-первых, кто сказал, что они - гранды?

Я сам это вижу. По уровню владения сишкой и уровню их алго.

> А во-вторых, вы сами только что написали - проблема в квалификации людей.

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

> При чём тут ЯП? Не умеете пользоваться топором - не берите его в руки.

Вон там топор - на ручку грабель насадили, стандартизаторам так проще всего было :)

> Честно? Мне плевать на всех дедушек вместе взятых с высокой колокольни. Авторитет
> не имеет никакого значения.

Поэтому вы будете генерить кислотные ифейсы пополам с г@нокодом и поучать других жизни? Казалось бы что в этом плане может пойти не так...

...
> Это вообще тут при чём?

Это вам небольшой реверанс на тему как машины работают. И что компилеры умеют на эту тему своим ходом.

> Как вы что-то проверите, если результат вычислений заранее неизвестен? Если все вычисления
> ради того и затевались, чтобы получить результат?

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

> Ох-хо-хо...

Йо-хо-хо, полкило бутрома... :)

> К вам приходить?))

Ктулху меня упаси...

...
> У них не "пока", у них в принципе проблемы. По-другому и быть не может.

Они хайповые. За что и страдают. Но все же ряд элегантных решений вот нащупали. А чего ради я должен игнорить прогресс типа борова вечно - хз.

>> 2) Часть вещей в C++ будет таки - в рантайме, с оверхедом.
> Да и пускай себе.

А таки неудобно будет когда хрустик обгонит на повороте в бенче...

> Нет там никаких граблей, есть лишь "программисты", которые не умеют читать документацию.

Я не понимаю этой веры некоторых господ в дрессировку дувуногих. За столько лет можно было бы уже и заметить что это так не работает. CVEхи пачками соврать не дадут.

> Оно и так всем, кроме вас, известно))

Я и вижу - что вы лажаете с советами на ровмно месте. Видимо не читав стандарт, так что даже не в курсе что врап signed и unsigned это 2 большие разницы.

> До-о... В очередной раз слышу про "кривость" С++... От тех, кто его не осилил))

Осиливать эту штуку в полном объеме - надо МакЛаудом быть. Особенно если нескольких стандартов, они довольно круто менялись по ходу пьесы.

А, да, сишникам тоже auto завезли. Прикол в том что у них до этого auto тоже было, но другое :)

> Во-от... Так и скажите: "Я не осилил". Громко и чётко. Прежде всего
> - себе самому. Признание проблемы - первый шаг к её решению.

У меня стойкое ощущение что вы не осилили все это - еще жестче, но пытаетесь меня чему-то учить. А вот это - EPIC FAIL.

> Не-а, вероятности то как раз складываются. Только не впрямую.

С фига ли? Если я могу повесить баг с вероятностью X и компилер ловит баг с вероятностью Y то в целом вероятность что баг долетит до юзера (X * Y). Потому что надо чтобы не сработали оба условия. Но с теоврером у вас не лучше чем с стандартами кажись. Оок!

> мелких, некритических ошибок, получите по итогу одну, но такую, что прям epic fail.

И обоснование этого ... что?

>> Проблема в том что тут ученики и учителя местами перепутаны.
> И с чувством юмора беда, да.

Ну, э, много у вас поклонников вашего юмора? Так, для статистики?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #384 Ответы: #391

391. Сообщение от ProfessorNavigator (ok), 02-Май-25, 19:49   +/
О-хо-хо... Ладно, я понял - весна виновата. Время сложное для некоторых людей, ничего не поделаешь. В общем извините, но строчить очередную простыню на ваше эм... мнение мне лень. Да и сказал я уже всё, что хотел. В очередной раз по кругу обсуждать одно и то же - не вижу смысла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #390 Ответы: #407

392. Сообщение от Аноним (392), 03-Май-25, 10:56   +/
>Вы можете дать лекцию как делать case folding всяких умляутов и каких там еще закорючек правилдьно
>Как по мне - меня устраивает подмножество "everything except null and /"

Вот ты и вывел принцип для усечения подмножества - символ, для которого существует само понятие большой/маленький, строчный/прописной, upper case/lower case. Всё остальное - откладываем в сторону. Я понимаю, что для общности подхода правильней отдавать как есть, но люди - не машины, и передай мне файл D096D09ED09FD090 не выглядит удобным для человека точно. На мой взгляд, потому-то и надо усекать множество всех вариантов, когда дело касается взаимодействия машины с человеком (хотя бы до тех пор, пока человек не научится читать байты напрямую, чтобы это не значило).
Проблема в том, что идея использовать юникод в именах каталогов и файлов при всех плюсах самого юникода, принесло кучу недостатков, которые уже всем т давно очевидны.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #338 Ответы: #395

393. Сообщение от anonymous (??), 03-Май-25, 15:24   +/
Да здравствует RADIX-50 !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

394. Сообщение от anonymous (??), 03-Май-25, 15:30   +/
И этот бред еще и плюсуют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #385

395. Сообщение от Аноним (-), 03-Май-25, 16:01   +/
> Вот ты и вывел принцип для усечения подмножества - символ, для которого
> существует само понятие большой/маленький, строчный/прописной, upper case/lower case.

Вон там примеров навалили где с этим нифига не просто все. Юникод большой и сложный, а чтобы вызвать десинк хватит и 1 несовпадения в рюхании вон того теми и этими. Это заведомое поле для багов и вулнов и Торвальдс очень прав на тему этой маздайшины.

> подхода правильней отдавать как есть, но люди - не машины, и
> передай мне файл D096D09ED09FD090 не выглядит удобным для человека точно.

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

Видимо, вот, для дружественности к пользователю какой-то процессинг сделали. И пользователь вообще недоумевает: как это, не удалось удалить файл?! Очень дружественно, теперь придумайте как этот крап из системы вообще стереть. Вот вам новый ВНЕЗАПНЫЙ квест!

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

Сам по себе юникод вообще никому и никак не мешает ибо UTF8 прекрасно вписался в "can contain anything except null and /". Но вот потуги процессить его регистр и что там еще...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #392

396. Сообщение от blkkid (?), 03-Май-25, 17:34   +/
на маках уже UEFI нет как такового
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

397. Сообщение от Васян (-), 03-Май-25, 23:32   +/
попробовал я при установке macos выбрать регистрозависимую фс. и после этого многие программы имели ошибки типа "не могу найти такой-то файл" потому что он написан не в том регистре символов ) лол. теперь всегода устанавливаю регистронезависимое как это по умолчанию заботливо предусмотрели инженеры в аппле )
Ответить | Правка | Наверх | Cообщить модератору

400. Сообщение от Аноним (400), 06-Май-25, 06:25   +/
Это называется не "ученик" - а, немного другим метким и резким словцом...
(настолько резким - что, не буду даже звучивать тут, да и зачистят 300% :]).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

401. Сообщение от Аноним (400), 06-Май-25, 06:38   +/
> Вы можете дать лекцию как делать case folding всяких умляутов и каких там еще закорючек правилдьно.

Как то ведь раньше без unicode прекрасно все жили, а кто то и ныне живёт (мин.в DOS'е).
И причём прекрасно живёт(в DOS же - лишь длины именам не хватает) - без этих всех топиковых проблем.


> А если иероглифы взять ...

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #338

402. Сообщение от Аноним (400), 06-Май-25, 06:48   +/
> Есть. ext2_x64.efi

И чем этот блоб лучше виндузятских блобов?...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #270

404. Сообщение от Аноним (400), 06-Май-25, 06:55   +/
Потому что программы требующие 4-ре десятичных числа - тупо более авдекватны.
(почему именно десятичных? чтобы легче/быстрей визуально отличались от маски)

/мимопроходил

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

405. Сообщение от Аноним (400), 06-Май-25, 06:57   +/
Тогда уж пиши IP6.66...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

406. Сообщение от Аноним (400), 06-Май-25, 07:00   +/
>> Совершенно не важно, как число лежит в памяти.
> Вообще-то важно. Ибо мы храним это число грубо говоря, как uint8_t whatever[20]. И вот тут возникает вопрос: whatever[0] это MSB или LSB этого числа? Сия договоренность также может влиять на транспортный формат. Если мы выстреливаем 20 байтов в провол - который из них будет первым в проводе?

В адекватных протоколах/стандартах - порядок бит и байт тоже стандартизирован собственно...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

407. Сообщение от Аноним (400), 06-Май-25, 07:04   +/
> и сказал я уже всё, что хотел.

Как же мы все рады... А, то уже колёсико мышки от прокрутки вашего DDOS читателей дымится.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #391 Ответы: #411

411. Сообщение от ProfessorNavigator (ok), 06-Май-25, 12:52   +/
> Как же мы все рады...

Кто это - "мы"? У вас раздвоение личности? Растроение? Расчетверение? 😱 И зачем вы всё это читаете?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #407 Ответы: #419

413. Сообщение от EmmGold (ok), 06-Май-25, 20:14   +/
У меня в паспорте вместо "ё" написано "е". И во многих документах теперь расхождение.
Предлагают обединить не только регистры, но и "еЕёЁйоЙОйОЙойо", чтоб наверняка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #312

414. Сообщение от EmmGold (ok), 06-Май-25, 20:23   +/
Так IP и так записывается "обычными", десятичными числами. Четыре байта, каждый записывается десятичным числом. Это просто четыре байта, четыре числа, четыре символа. Как его ещё записывать?
Некоторые из четырёх символов делают пятнадцать и героически это преодолевают...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

415. Сообщение от EmmGold (ok), 06-Май-25, 20:25   +/
привет андроид, где несколько тысяч фото в одной папке намерно вешают систему и хрен там что найдёшь...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #417

417. Сообщение от BrainFucker (ok), 06-Май-25, 21:15   +/
Так там потому что классическая ФС (ext4 или что там сейчас). Ну и в моём комментарии не было речи о том что надо все файлы в одной папке отображать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #415

419. Сообщение от Аноним (419), 07-Май-25, 11:43   +/
один вредина зачистил тебе ответ (без нарушений правил любых)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #411


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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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