3 Commits
Author SHA1 Message Date
ew8bakandClaude Opus 5 f88b1615e7 fix(serial): контракт SerValid — платформенный, ноль значит разное
Ноль на Unix и на Windows означает не одно и то же, и одной проверкой тут не
обойтись. На Unix это законный дескриптор (при закрытом стандартном вводе
fpOpen отдаёт именно его), а ядро Windows нулевой хендл не выдаёт никогда —
там ноль это либо отказ RTL, либо неинициализированное поле. Внутренний путь
был безопасен и раньше (SerOpen переводит ноль RTL в SER_INVALID_HANDLE, свои
поля инициализируются им же), но публичный контракт для значения, пришедшего
извне, оказывался неверным. Теперь проверка разведена по платформам.

★Стенд научился ПРОГОНЯТЬ windows-ветку, а не только компилировать её.
Заглушка модуля Serial — чистый Паскаль, поэтому ветку можно собрать и
запустить прямо на Linux: test/platform/win_probe проверяет перевод нулевого
хендла в SER_INVALID_HANDLE, ответ SerValid и правило имени COM10+. До сих пор
у windows-пути обёртки не было никакого поведенческого покрытия вовсе.

Негативный контроль: если убрать windows-ветку из SerValid, прогон падает на
«★нулевой хендл под Windows негоден».

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bkwwyj7xVRrqnSVEseTRfV
2026-08-24 22:43:14 +03:00
ew8bakandClaude Opus 5 05ba39fdad feat(serial): своя обёртка последовательного порта — macOS собирается
RTL-модуль Serial собирается только для [android, linux, netbsd, openbsd,
win32, win64] — Darwin в списке нет (rtl-extra/fpmake.pp). Из-за этого под
macOS CAT по последовательному порту стоял заглушкой, а CWKeyer не собирался
вовсе.

★Скопировать чужой исходник было нельзя. Serial.SerSetParams кладёт B-константу
скорости прямо в c_cflag — идиома Linux, где это битовая маска. На BSD и macOS
B115200 это просто ЧИСЛО 115200, и в c_cflag прилетает $1C200: CLOCAL | HUPCL |
CCTS_OFLOW плюс мусор в поле CSIZE. Молча включается аппаратный CTS-flow, и
передача встаёт, если железка не держит CTS, — а ошибки никакой, порт
«открылся».

Новый SerialPort.pas:
* Unix — termios напрямую, Linux и macOS ОДНИМ путём (разница спрятана в
  константах RTL; Darwin даёт и termio, и все TIOCM_*). Скорость только через
  CFSetISpeed/CFSetOSpeed, c_cflag собирается с нуля чистой SerCFlags;
  CRTSCTS — исключительно по явной просьбе; сырой режим и VMIN/VTIME явные;
  open с O_NONBLOCK и снятием флага сразу после (часть USB-драйверов, как и
  tty-устройство на маке, висит в open до DCD).
* Windows — тонкая переадресация в RTL Serial: там он есть и в termios не лезет.
* Неуспех SerOpen на ВСЕХ платформах даёт SER_INVALID_HANDLE (RTL возвращал 0
  под Windows и −1 под Unix, из-за чего вызывающие держали свои развилки).
  Проверка — SerValid.

Точки вызова: CATSerial и CWKeyer переведены на обёртку, заглушка
CAT_SERIAL_STUB и платформенные {$IFDEF} вокруг хендлов убраны. Имена портов по
умолчанию и подсказка в настройках теперь платформенные (SerDefaultPortName /
SerPortNameHint): на маке порт зовётся /dev/cu.usbserial-XXXX, и '/dev/ttyS0'
там — заведомо неверная подсказка; осмысленного умолчания не существует,
поэтому пусто.

Новый стенд test/serial (36 проверок) — на псевдотерминале: открытие, termios
обратным чтением, ★«CRTSCTS сам не включился», ★«в c_cflag нет ничего, кроме
наших флагов», формат через чистую SerCFlags (обратным чтением его не
проверить: pty восьмибитно-чистый и молча меняет CS7 на CS8), обмен, срок
таймаута, CR не превращается в CR+LF, эха нет, и сквозной прогон CAT через
обёртку. Негативный контроль: с `or Cardinal(BitsPerSec)` в SerSetParams (та
самая идиома, что ломает RTL на BSD) проверка c_cflag падает — «1CAB0 против
8B0».

test/platform расширен: теперь сим-компилирует и SerialPort, для его
Windows-ветки добавлена заглушка модуля Serial с теми же сигнатурами.

Модемные линии (DTR/RTS/CTS/DSR/CD/RI) на pty не проверяются — ioctl TIOCM*
там не работает; это остаётся на живой порт.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bkwwyj7xVRrqnSVEseTRfV
2026-08-24 22:09:44 +03:00
ew8bakandClaude Opus 5 f2ecd63fe1 fix(platform): win64-сборка падала на GetEnvironmentVariable
Модуль Windows стоит в uses ПОСЛЕ SysUtils, поэтому его трёхпараметрический
GetEnvironmentVariable(PChar;PChar;DWORD) перекрывает однопараметрический из
SysUtils, и три вызова в PlatformUtils падали с «wrong number of parameters».
Лечение — явная квалификация SysUtils.GetEnvironmentVariable.

★Сломалось это не сейчас: unit Windows появился в uses ещё в d209697 (вместе с
QueryPerformanceCounter для монотонных часов), и с тех пор под win64 не
собиралось вовсе — просто сборочная машина туда не заходила. GetAppCfgDir с
%APPDATA% живёт с e9f4bf1 и до d209697 работал.

Новый стенд test/platform. Кросс-RTL обычно не установлен, поэтому ветки
{$IFDEF WINDOWS} и {$IFDEF DARWIN} на Linux не компилируются ВООБЩЕ, и ошибка в
них всплывает только на сборочной машине. Стенд переписывает копию
PlatformUtils.pas так, чтобы платформенные условия читались как свои
(-dSIMWIN / -dSIMMAC), и компилирует без линковки (-Cn): системных функций тут
нет, но синтаксис, типы и — главное — разрешение имён проверяются
по-настоящему. Для Windows подкладывается заглушка unit Windows, объявляющая
ровно те имена, которыми настоящий перекрывает SysUtils; на ней и держится вся
проверка.

★Негативный контроль: на коде до правки стенд выдаёт РОВНО те же три ошибки
(строки 210, 271, 273), что и сборочная машина.

Чего он не делает: живых вызовов системных счётчиков — их правильность
доказывает только прогон на самой платформе.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bkwwyj7xVRrqnSVEseTRfV
2026-08-24 21:31:59 +03:00