Адрес в макросе?

Адреса функции известны ещё на этапе компиляции

Василий Банников, на этапе линковки. И только если линкуется не-PIE исполняемый файл. И только для функций из этого же исполняемого файла. В противном случае -- нет, адреса функций неизвестны до того момента, пока динамический линковщик (или стаб встроенный в PIE) не вычислит их не не запишет в GOT.

Почему scanf_s("%[^3]", str) при считывании символа '3' просто останавливается на этом символе, а не переходит к следующему?

Мне нужно считывать из файла строки с пробелами, оканчивающиеся символом переноса

Qubc, можно использовать scanf("%[^\n] ", str); (заметь пробел после форматной строки, извлекающий символ конца строки на котором остановился матчинг), и знать, что строка считана в str, но конец строки в неё не попал.

Как git изменяет содержимое файла?

Но, точно "Полные копии всех состояний не хранятся".

Vitsliputsli, слушай, ну с чем ты споришь, если можно просто взять и убедиться, что по умолчанию хранятся?:

$ git init .
$ hexdump -Cv /dev/urandom | head -n 100000 > a
$ stat a
  File: a
  Size: 7900000         Blocks: 15432      IO Block: 4096   regular file

Вот подопытный файл размером почти 8M.

$ git add a
$ git commit -m 'version 1'
[master (root-commit) b36ee5cb126b] version 1
 1 file changed, 100000 insertions(+)
 create mode 100644 a
$ git cat-file -p b36ee5cb126b
tree f5870cee82fda72446a4dd3be8ebaeffe46035a3
author <[e-mail]> 1679909736 -0700
committer <[e-mail]> 1679909736 -0700

version 1
$ git cat-file -p f5870cee82fda72446a4dd3be8ebaeffe46035a3
100644 blob 65a9d4359a613ac58723324b2da83294673ca018    a
$ stat .git/objects/65/a9d4359a613ac58723324b2da83294673ca018 
  File: .git/objects/65/a9d4359a613ac58723324b2da83294673ca018
  Size: 4090218         Blocks: 7992       IO Block: 4096   regular file

Вот файл блоба с его первоначальным состоянием размером 4М.

$ echo 'some more data' >> a
$ git commit -a -m 'version 2'
[master 73e8c999ed23] version 2
 1 file changed, 1 insertion(+)

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

$ git cat-file -p 73e8c999ed23
tree 57ce1455664bd5027552860b713779c226c70fe9
parent b36ee5cb126b84100984c5b44f6d1f39155bd747
author <[e-mail]> 1679909809 -0700
committer <[e-mail]> 1679909809 -0700

version 2
$ git cat-file -p 57ce1455664bd5027552860b713779c226c70fe9
100644 blob 22f30336c84a6f20376a83fc04977797969f80b4    a
$ stat .git/objects/22/f30336c84a6f20376a83fc04977797969f80b4 
  File: .git/objects/22/f30336c84a6f20376a83fc04977797969f80b4
  Size: 4090233         Blocks: 7992       IO Block: 4096   regular file

Вот ещё один файл блоба, из нового коммита, с добавленной одной строчкой, почти такого же размера -- 4M.

В эту игру можно играть целый день:

$ for a in `seq 3 100` ; do echo 'some more data' >> a ; git commit -a -m "version $a" ; done
...
$ du -sh .git/objects/
392M    .git/objects/

100 коммитов с блобами по 4М, а каждый коммит только по одной строчке в конец добавил.

Как git изменяет содержимое файла?

например мой реп в 30Мб

Vitsliputsli, anecdotal evidence такой anecdotal evidence.

Как git изменяет содержимое файла?

по данной вами же ссылке написано

Vitsliputsli, точная цитата такая:

Первоначальный формат для сохранения объектов в Git называется «рыхлым» форматом (loose format). Однако, время от времени Git упаковывает несколько таких объектов в один pack-файл для сохранения места на диске и повышения эффективности.

это больше исключение

Какое же это исключение, если это поведение по умолчанию, а упаковка -- это необязательная оптимизация. Что как бы совсем не

Гит хранит разницу состояний между коммитами – diff.

Как git изменяет содержимое файла?

Полные копии всех состояний не хранятся.

По умолчанию хранятся.

Как в виртуальных процессорах устроена виртуальная память?

любой доступ к памяти, нужно в любом случае, обратится к tlb

SergeySerge11, да.

в любом случае, это вызов функции с передачей параметров, и разбор адреса на n кусков, пара проверок.

Нет, не в любом. В лучшем случае (попадание в собственный TLB QEMU) это извлечение битового поля из виртуального адреса, загрузка значения (кешированный виртуальный адрес) из массива записей TLB по этому индексу и сравнение. Если сравнение успешное -- загрузка ещё одного значения (кешированный физический адрес). На это можно легко посмотреть, если запускать QEMU с ключами -d in_asm, op_opt,out_asm
Например такой вот код

movb    (%rbx), %al
        jmp     1f
1:

генерирует такой вот вывод:

IN:
0x001000ee:  8a 03                    movb     (%rbx), %al
0x001000f0:  eb 00                    jmp      0x1000f2

OP after optimization and liveness analysis:
 ld_i32 tmp11,env,$0xfffffffffffffff0     dead: 1  pref=0xffff
 movi_i32 tmp12,$0x0                      pref=0xffff
 brcond_i32 tmp11,tmp12,lt,$L0            dead: 0 1

 ---- 00000000001000ee 0000000000000000
 qemu_ld_i64 tmp0,rbx,ub,2                dead: 1  pref=0xf
 deposit_i64 rax,rax,tmp0,$0x0,$0x8       sync: 0  dead: 0 1 2  pref=0xffff

 ---- 00000000001000f0 0000000000000000
 goto_tb $0x0
 movi_i64 tmp3,$0x1000f2                  pref=0xffff
 st_i64 tmp3,env,$0x80                    dead: 0 1
 exit_tb $0x7f02d017d480
 set_label $L0
 exit_tb $0x7f02d017d483

OUT: [size=152]
  -- guest addr 0x00000000001000ee + tb prologue
0x7f02d017d540:  8b 5d f0                 movl     -0x10(%rbp), %ebx
0x7f02d017d543:  85 db                    testl    %ebx, %ebx
0x7f02d017d545:  0f 8c 58 00 00 00        jl       0x7f02d017d5a3
0x7f02d017d54b:  48 8b 5d 18              movq     0x18(%rbp), %rbx
0x7f02d017d54f:  48 8b fb                 movq     %rbx, %rdi
0x7f02d017d552:  48 c1 ef 07              shrq     $7, %rdi
0x7f02d017d556:  48 23 7d e0              andq     -0x20(%rbp), %rdi
0x7f02d017d55a:  48 03 7d e8              addq     -0x18(%rbp), %rdi
0x7f02d017d55e:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d561:  48 81 e6 00 f0 ff ff     andq     $0xfffffffffffff000, %rsi
0x7f02d017d568:  48 3b 37                 cmpq     (%rdi), %rsi
0x7f02d017d56b:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d56e:  0f 85 3b 00 00 00        jne      0x7f02d017d5af
0x7f02d017d574:  48 03 77 18              addq     0x18(%rdi), %rsi
0x7f02d017d578:  0f b6 1e                 movzbl   (%rsi), %ebx
0x7f02d017d57b:  48 8b 4d 00              movq     (%rbp), %rcx
0x7f02d017d57f:  88 d9                    movb     %bl, %cl
0x7f02d017d581:  48 89 4d 00              movq     %rcx, (%rbp)
  -- guest addr 0x00000000001000f0
0x7f02d017d585:  66 90                    nop
0x7f02d017d587:  e9 00 00 00 00           jmp      0x7f02d017d58c
0x7f02d017d58c:  48 c7 85 80 00 00 00 f2  movq     $0x1000f2, 0x80(%rbp)
0x7f02d017d594:  00 10 00
0x7f02d017d597:  48 8d 05 e2 fe ff ff     leaq     -0x11e(%rip), %rax
0x7f02d017d59e:  e9 75 2a e8 ff           jmp      0x7f02d0000018
0x7f02d017d5a3:  48 8d 05 d9 fe ff ff     leaq     -0x127(%rip), %rax
0x7f02d017d5aa:  e9 69 2a e8 ff           jmp      0x7f02d0000018
  -- tb slow paths + alignment
0x7f02d017d5af:  48 8b fd                 movq     %rbp, %rdi
0x7f02d017d5b2:  ba 02 00 00 00           movl     $2, %edx
0x7f02d017d5b7:  48 8d 0d bd ff ff ff     leaq     -0x43(%rip), %rcx
0x7f02d017d5be:  ff 15 0c 00 00 00        callq    *0xc(%rip)
0x7f02d017d5c4:  8b d8                    movl     %eax, %ebx
0x7f02d017d5c6:  e9 b0 ff ff ff           jmp      0x7f02d017d57b
0x7f02d017d5cb:  90                       nop
0x7f02d017d5cc:  90                       nop
0x7f02d017d5cd:  90                       nop
0x7f02d017d5ce:  90                       nop
0x7f02d017d5cf:  90                       nop
  data: [size=8]
0x7f02d017d5d0:  .quad  0x000055895af47e50

Если отсюда выкинуть служебный код остаётся следующее:

Загрузка регистра %rbx виртуального процессора в %rbx:
0x7f02d017d54b:  48 8b 5d 18              movq     0x18(%rbp), %rbx

Вычисление адреса записи в TLB QEMU для виртуального адреса в %rbx:
0x7f02d017d54f:  48 8b fb                 movq     %rbx, %rdi
0x7f02d017d552:  48 c1 ef 07              shrq     $7, %rdi
0x7f02d017d556:  48 23 7d e0              andq     -0x20(%rbp), %rdi
0x7f02d017d55a:  48 03 7d e8              addq     -0x18(%rbp), %rdi

Выделение адреса страницы из виртуального адреса в %rbx:
0x7f02d017d55e:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d561:  48 81 e6 00 f0 ff ff     andq     $0xfffffffffffff000, %rsi

Сравнение адреса страницы и виртуального адреса адреса в TLB
0x7f02d017d568:  48 3b 37                 cmpq     (%rdi), %rsi

Если не сходится -- перейти к вызову обработчика эмуляции TLB процессора:
0x7f02d017d56b:  48 8b f3                 movq     %rbx, %rsi
0x7f02d017d56e:  0f 85 3b 00 00 00        jne      0x7f02d017d5af

Иначе (сошлось) -- вычислить "физический" адрес по виртуальному:
0x7f02d017d574:  48 03 77 18              addq     0x18(%rdi), %rsi

Загрузить байт из памяти:
0x7f02d017d578:  0f b6 1e                 movzbl   (%rsi), %ebx

Записать загруженный байт в регистр виртуального процессора %al:
0x7f02d017d57b:  48 8b 4d 00              movq     (%rbp), %rcx
0x7f02d017d57f:  88 d9                    movb     %bl, %cl
0x7f02d017d581:  48 89 4d 00              movq     %rcx, (%rbp)

Т.е. 11 команд на преобразование виртуального адреса в "физический" в случае успеха.

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

Нет.

Или вот чтение инструкции из EIP, каждое чтение по адресу, прочесть инструкцию PC+1 будет перед тем как исполнить, на фазе извлечения опять это делать?

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

Как реализован внутри std::tm?

почему выходит вот так:

std::tm tm;
tm.tm_hour+=1600;
std::cout<<tm.tm_mon<<std::endl;//2

Даниил, потому что в этом коде ты не инициализировал переменную tm и печатаешь мусор.

Как быстро округлить timestamp до секунд, минут, часов, дней и т.д.?

unix timestamp

Pavel K, правильнее было бы сказать, что часы нужны в UTC+0.

Как округлить timestamp

Уточни "округлить" заодно: 00:00:01 -> 00:00:00, 00:00:30 -> 00:01:00 ?
2 января -> 1 января, 17 января -> 1 февраля?

Как быстро округлить timestamp до секунд, минут, часов, дней и т.д.?

Если с округлением времени всё относительно легко

часовые пояса/летнее/зимнее время, не, не нужно?

Как в виртуальных процессорах устроена виртуальная память?

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

Vindicar, я помню, что видел упоминания этой техники ещё в конце 90х, но сейчас не могу найти никаких конкретных данных о том, что происходит и на каких процессорах эта техника должна была работать. Процессоры вплоть до i486 вообще не имели архитектурно-видимого кеша, т.е. с их точки зрения кеш был неотличим от основной памяти.
Возможно эта техника была нацелена на внутренний пайплайн процессора, но опять же, пайплайн появился в i486, а уже в pentium pro появилось детектирование самомодифицирующегося кода сбрасывающее пайплайн при обнаружении записи в адреса из которых были прочитаны инструкции в настоящий момент находящиеся в пайплайне.
Короче, это, по всей видимости, очень ограниченный анти-отладочный трюк, работающий только на небольшом подмножестве x86, скорее всего только на i486 и pentium.

Почему компилятор пишет, что типы не совпадают?

Потому что ты определил функцию вверху без параметров int calculate();

Hemul GM, объявил, а не определил.

Почему компилятор пишет, что типы не совпадают?

я всё равно не могу ввести действие

ваня бро, пробел добавь во вторую форматную строчку: scanf("%d ", &num2);
Без пробела в action попадает символ конца строки который ты вводишь чтобы закончить num2.

Почему возникает проблемы при закрытие файла в C++ с использованием std.io?

Проблема в том, что при проверке через обычный if и else выдаётся "Не удалось открыть файл".

Так ясен пень, что не удалось. Разбирайся почему.

if ((f = fopen(path, "ab+");
{
printf ("Не удалось открыть файл");
}

Тут какая-то фигня написана, а не код на С.

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

Ты спросил: почему возникают проблемы, а в качестве проблемы привёл скриншот окошка debug assertion failed. Ответ: потому что файл не открылся.

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

Почему gcc: command not found в этом случае?

Ага, я вижу, что этот проект в процессе сборки хочет компилировать не только для --host но и для --build, чтобы собрать какие-то вспомогательные программы mkerrcodes и mkheader, так что вызов gcc имеет смысл.

Надо разбираться, что случилось с твоим хостовым gcc.

Почему gcc: command not found в этом случае?

cryptohas, прекрасно, как видишь никаких Makefile там нет. Возможно ты сконфигурировал проект с другими настройками до этого а теперь страдаешь от последствий.

Почему gcc: command not found в этом случае?

в Makefile тупо прописана команда "gcc"?

cryptohas, обычно если есть скрипт configure, то Makefile генерируется во время выполнения этого скрипта, так что там не может ничего быть тупо прописано. Генерируется он из Makefile.in либо из Makefile.am

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

Почему поведение fscanf ( stdin, "%c", &c ) различается при чтении EOF в msvc и gcc?

Стандартом это поведение не регулируется.

Стоило бы уточнить, какой стандарт имеется в виду, потому что и стандарт C и POSIX однозначно говорят о том, что никакого чтения за концом файла быть не может.

Почему поведение fscanf ( stdin, "%c", &c ) различается при чтении EOF в msvc и gcc?

обработка, видимо, зашита в стандартной библиотеке.

res2001, если это -- действительно libc M$, то там нет никакой специфичной обработки ^Z.

Почему поведение fscanf ( stdin, "%c", &c ) различается при чтении EOF в msvc и gcc?

обработка, видимо, зашита в стандартной библиотеке

res2001, в линуксе это делается в line discipline внутри ядра, а управляется через ioctl. Например командой stty -icanon -isig можно полностью отключить интерпретацию ^C/^D/^Z/…

Я бы ожидал, что и в венде это всё зарыто, если и не в ядро, то всё равно ниже libc. В документации на SetConsoleMode есть флаг ENABLE_PROCESSED_INPUT в описании которого есть упоминание ^C и "других управляющих символов", но не написано, входит ли туда ^Z.