historydev, все зависит от того что ты себе качаешь. Современный прикладной разработчик на 99%
вообще не полезет в глубину тех глубин которые ты хочешь для себя копать.
Вот тебе Сергей задал вопрос - зачем? Вот допустим ты по нужному оффсету памяти
прочитал значние 0x00. И что дальше? Какие ты сделаешь выводы? Куда ты с этим значением
пойдешь. Мы еще даже не пытаемся мечтать о том что ты реверс инженер. Но если
нет - то зачем ты полез в сырую память?
Я вот люблю полазить по всяким биг-дата файлам parquet/orc но я знаю что я там ищу.
Я проверяю свои гипотезы и смотрю как система среагировала. Создала индекс или нет.
Включила сжатие LZW или нет.
historydev, займись программированием микро-контроллеров. Там обычно нет операционки
и программист - анархист. Творит что хочет. Вся память и порты доступны. Но микро-контроллер
ограничен в ресурсах и обычно делает одну узкую задачу.
historydev, выбрось это. Это старая чепуха из 20-го века которая применялась в ОС MS-DOS
в x86 / real mode и позволяла адресовать не более 1 мегабайта. Сам посчитай. 16 разрядный сегментный
регистр который сдвигался влево на 4 бита позволял тебе видеть только 20 бит адресов.
Чувак это очень мало.
Ты определись точнее со своей платформной. Ты сначала написал про aarch64 и потом про android.
Там скорее всего везде 64 битная плоская модель памяти но я-бы отдельно уточнил по андроиду
поскольку есть сомнения.
Да. На сях - тоже возникает Segmentation Faul. Под sudo - тоже самое на 64х битном Linux.
Я читернул слегонца после этого и спросил зазнайку Gemini. Вот что он предлагает в
качестве причин:
Memory Segmentation: Linux uses memory segmentation to divide memory into sections with specific permissions (read, write, execute) for different processes. This ensures isolation and prevents programs from accessing memory they shouldn't.
Address Space: Each process has its own virtual address space, typically 4GB on 32-bit systems. This virtual address space is a map that translates to physical memory locations.
Unaccessible Memory: The address 0x10000000 (2^28) is very high in the virtual address space. On most systems, this falls within the kernel memory space, which is off-limits to user processes.
У нас вершин = 3 штуки. И ребер - по количеству единичек в верхнем треугольнике. Тоесть одно
ребро. Которое соединяет вершины номер 2 и 3. Или 3 и 2 если считать граф неориентированным.
Это кстати тебе поинт. Ты должен дать больше контекста. Графы разные бывают.
И кстати я допустил ошибку. У меня вершина 3 сама с собой не связана. Видишь не подумал
и внес такой вот парадокс. Теперь - еще подумай будут ли считаться у тебя вершины связаны сами
с собой.
На это нет стандарта. Это просто договорняк у тебя в голове с самим собой.
Язык Си тоже позволяет внуть кода вставлять ассемблерные вставки. Правда ассемблер там - не самый
комфортный. Но по возможностям вроде-бы достаточно чтоб делать все что надо.
вообще не полезет в глубину тех глубин которые ты хочешь для себя копать.
Вот тебе Сергей задал вопрос - зачем? Вот допустим ты по нужному оффсету памяти
прочитал значние 0x00. И что дальше? Какие ты сделаешь выводы? Куда ты с этим значением
пойдешь. Мы еще даже не пытаемся мечтать о том что ты реверс инженер. Но если
нет - то зачем ты полез в сырую память?
Я вот люблю полазить по всяким биг-дата файлам parquet/orc но я знаю что я там ищу.
Я проверяю свои гипотезы и смотрю как система среагировала. Создала индекс или нет.
Включила сжатие LZW или нет.
А тебе для чего? Для чего тебе?