- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
// https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Common-Function-Attributes.html
access
access (access-mode, ref-index)
access (access-mode, ref-index, size-index)
// примеры:
__attribute__ ((access (read_only, 1))) int puts (const char*);
__attribute__ ((access (read_only, 1, 2))) void* memcpy (void*, const void*, size_t);
__attribute__ ((access (read_write, 1), access (read_only, 2))) char* strcat (char*, const char*);
__attribute__ ((access (write_only, 1), access (read_only, 2))) char* strcpy (char*, const char*);
__attribute__ ((access (write_only, 1, 2), access (read_write, 3))) int fgets (char*, int, FILE*);
В GCC 10 какой-то новый атрибут access появился, чтоб более строго что-то там гарантировать:
The access attribute enables the detection of invalid or unsafe accesses by functions to which they apply or their callers, as well as write-only accesses to objects that are never read from. Such accesses may be diagnosed by warnings such as -Wstringop-overflow, -Wuninitialized, -Wunused, and others.
The access attribute specifies that a function to whose by-reference arguments the attribute applies accesses the referenced object according to access-mode. The access-mode argument is required and must be one of three names: read_only, read_write, or write_only. The remaining two are positional arguments.
The required ref-index positional argument denotes a function argument of pointer (or in C++, reference) type that is subject to the access. The same pointer argument can be referenced by at most one distinct access attribute.
The optional size-index positional argument denotes a function argument of integer type that specifies the maximum size of the access. The size is the number of elements of the type referenced by ref-index, or the number of bytes when the pointer type is void*. When no size-index argument is specified, the pointer argument must be either null or point to a space that is suitably aligned and large for at least one object of the referenced type (this implies that a past-the-end pointer is not a valid argument). The actual size of the access may be less but it must not be more.
Follow us!
void*, int
можно было сказать, что первый парамтер есть указатель на такую-то структуру, если второй равен такой-то конгстанте
А для самого конпелятора это вроде просто макросы-пустышки.
Эту хуйню можно потом через Why3 в язык для SMT солверов экстрактить. И даже в Coq, чтоб руками доказывать.
Придумать новый язык с такой типизацией, как нам нравится, но обратно совместимый с сями, и транспилер сделать из него в си?
А кресты и objc изначально превращали код в си (хотя про кресты я не уверен). Сейчас конечно конечно уже нет.
Кстати, С++ не полностью обратно совместим с няшной, а вот обж вроде как полностью.
- мм, простота и понятность C++, помноженная на лаконичность и выразительность ObjC, что может быть лучше
Объективное крестоговно/CLI. То же самое, но с удобством управления ресурсами в C#.
К сожалению его почему-то не пильнули.
а у эппла можно в одном исходнике мешать обжектив, няшную и кресты, красиво вызывая одно из другого, а в соседнем сырце на Свифте вызывать продукты этой жизнедеятельности
Виндузятник из крестов трогает няшный w32api примерно как яблоник трогает какой нить core foundation, наверное
У меня никаких "проектов" и "солюшенов" нет, я просто пишу сборочный скрипт и компилирую что угодно с чем угодно.
алсо, его можно собирать из командной строки (но если у тебя сложная логика сборра, то заебешься)
а кодить потом в notepad++ ?
cmake то ещё говнище, конечно. Но по сравнению с мсбилдой он на порядки удобнее. Да и к венде гвоздями не прибит.
>винде
ну если ты пишеш не только под винду, то понятно, что не нужно хранить проект в студийном говне
Да, и кастомные скрипты ещё. Но их реально проще выписать и переписать на чём-то другом. Особенно с учётом того, что студия все настройки по 4 раза повторяет если через гуйню править.
ну да, но тебе похуй, если ты через гуйню всё делаешь
А потом ты видишь, что какая-то опция включена в 5 ворециях сборки из 8 и думаешь -- они это специально или так получилось? Комментов же гуйня не даёт написать.
с гуйней еще есть такая проблема, что можно случайно вкоммитить путь
c:\users\booratiho\
и незаметить
Там что-то есть, но через гуйню эти дефолты совсем пиздец настраивать, проще руками написать xml'ку.
В основном очередным самодельным говноязыком. Ну и тем, что многие важные вещи вообще не поправить не залезая в код (а он на крестах).
А если собирать стандартные проекты -- сойдёт.
Что-нибудь адекватное из императивных языков. Ибо сам cmake по сути и является императивным DSL, нахуяренным на коленке. Он даже не пытается косить под декларативность.
Но cmake императивный и его как-то парсят... Полностью исполняют весь скрипт, как и гредл, на самом деле.
Вот отредактировать что-то из гуйни -- да, неразрешимая задача. Но никто вроде уже и не пытается.
Ну конпеляцию можно же прервать. Вот тебе и решение хальтинг проблема.
ну то есть какие у нас есть варианты?
1) пистон
2) ???
- каждому своё, но я уж лучше на велосипедном поделии попишу, чем на этой отрыжке wannabe-программистов
Ну удачи там. В js хотя бы переменные из фрейма вызывающей функции не наследуются. И массивы не через жопу сделаны.
есть же какая-то билд-система на лиспе, кстати
*впрочем, я послал его нахуй год-два-три назад, когда оказалось что сишку надо компилить через рулы для плюсов, а компилятор самому выставлять через классическую переменную окружения (СС вроде)
но решение очень неоднозначное
Как что-то уникальное. qt creator вон из cmake их умеет получать. Да и из make опции конпелятора можно надрать в теории.
но из make вряд-ли)
Впрочем, jциферкам может оно и не надо. Настоящему индейцу ctags+vim и заебись
Но editorconfig это хорошая идея, да.
Да это особо и не надо.
Самое главное -- макросы, инклуды, прочие опции конпелятора которые влияют на код. Вот это вот самое нужное в "проекте". Без этой инфы проще взять "ноутпад++" и не заморачиваться с "ИДЕ".
Да, подобная хрень вполне нужна и полезна, но если эта хрень работает только в одной конкретной IDE, на одной конкретной платформе, то это херня.
он прибит гвоздями к win32api например, и на другие платформы впринципе не портируется.
Или например он написан под cocoa и appkit и никогда не будет собираться ни под что кроме мака
Потому что тогда получается так, что только на винде его и можно удобно редактировать, и только вот в этой конкретной IDE, а бывают ведь и другие ОС, и еще можно кросскомпилировать и удаленно отлаживать что-то, пользуясь при этом не виндой.
Ты кстати в своем Makefile вполне можешь завязаться на наличие perl, bash, sed, awk, и удачи тебе в сборке это под другую ОС
Будто бы есть что-то хорошее в том, что код под винду собирается только под виндой.
> Ты кстати в своем Makefile вполне можешь завязаться на наличие perl, bash, sed, awk, и удачи тебе в сборке это под другую ОС
perl, bash, sed, awk в винде можно из msys2 взять, с этим как-то попроще, чем если какую-то хуйню, наглухо завязанную на виндовый компилятор и SDK пытаться собирать в прыщах.
Ну вот например есть проект (беру от балды)
https://plugring.farmanager.com/plugin.php?pid=312&l=ru
Это плагин в фару для посылки говна через MAPI (понятия не имею, кому это нужно).
MAPI есть только под винду, и FAR есть толкьо под винду.
На кой чорт тут вообще думать про другие ос?
>perl, bash, sed, awk в винде можно из msys2 взят
я видел попытки собрать всякое такое говно на винде, и это всегда был ад:
то у пользователя путь с ебанутыми символами, то еще что.
Кстати, завязка на bash тоже не позволит тебе портироваться дальше GNU:)
Ну вот так потом и получается, что "FAR есть толкьо под винду". Заебись подход.
типа разработчик ФАРа должен был обязательно сделать его кроссплатформенным, чтобы лялиховоды вкусили плоды его работ? а не сильно ли это самонадеянно звучит?
Очевидно, все эти технологии не нужны, ведь они не кросс-платформены
> MAPI есть только под винду, и FAR есть толкьо под винду.
> На кой чорт тут вообще думать про другие ос?
А на кой черт надо так писать свои IDE и SDK, что собирать под винду эту хуиту возможно только из винды? Если у меня в контроллере некая OS, мне не надо почему-то в контроллер засовывать компилятор чтоб собрать под эту микроконтроллерную OS некую херню.
Эм, по-моему тут всё очевидно. Как и с маком. Манагеры сверху сказали -- нам нужен вендор-лок, чтобы винда/макбуки лучше продавались.
- у тебя весь мир в контроллере, даже набо, даже нах-нах, мы уже поняли.
А винда тут при чём?
Почему прыщепоттеринг не хочет писать кросс-платформенный софт, и предлагет свой софт на BSD даже не тестировать?
В теории я, конечно, должен юзать последнюю версию и течь, а остальные просто снести. Но на практике это не работает.
узнать, что у тебя теперь и новая не ставится, и старая не до конца удалилась
и все другие SDK и студии теперь у тебя тоже не ставятся, и пишут неизвестную ошибку.
И на форумах советуют сделать sfc /scannow, а более умные советуют переустановить Windows.
И только один чел нашел procmonом какой GUID в реестре нужно удалить, чтобы всё заработало
prn.c , лол
https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42073
Какой смысл делать кросс компиляцию, тратить вермя на портирование SDK, разбираться с особенностями компиляторов (к примеру, экспорировать функции у линкера из вижала и gcc нужно по разному) если твой код все равно не будет работать на других ос?
Почему у тебя "будет или не будет некий код работать под другими ОС" как-то увязывается с тем, "можно или нельзя компилировать этот код из некоторой-ОС под единственую-ОС-в-которой-код-будет-работать" ? Как это вообще соотносится?
Твой код тоже не компилируется на bolrand c 3 под DOS, но тебя это нисколечки не волнует
А исошки у нас и так обычно и образы дисков и с MBR, иначе как бы они с флешки грузились (без руфусов)?
SetVolumeMountPoint("c:\\гавно", "d:\\гавно.bin") ?
Кстати, можешь попробовать еще vhdx: это и формат дисков для hyper-v, и их disk manager умеет прикручивать. Сейчас это модно:)
Он сложный, лень... А обычные vhd я умею генерить и цеплять, там простенький хедер в конце и всё.
Я смутню помню, что там заголовок тома показывают драйверам файловых систем, и говорят "to je tvoje hovinko?", и кто первый согласится -- тот и прикручивает
Поверх него драйвер партиций (который там понимает MBR, GPT, вот это всё), потом volumgr (который отличает софтварные рейды -- dynamic вот это всё), и потом файлуха
А почему возникла ситуация, что на это надо специально тратить время? Вот например взять некую ОС под микроконтроллеры, пусть это например будет RetroBSD, она предоставляет POSIX API и программное окружение unix и из нее даже можно компилировать код под нее же, притом работает она на микроконтроллере Microchip PIC32 с 128 килобайтами памяти и 512 килобайтами Flash: https://habr.com/ru/post/143679/
Почему-то там не возникало ситуации, что надо тратить время чтоб что-то под эту ОС собирать не из-под нее же. Почему? Может быть потому, что для RetroBSD никто не вендорлочил SDK и тулкит таким образом? Почему на винде такое возникло? Нахуя было вендорлочить? Хорошо ли это?
Потому что не все компиляторы совместимы друг с другом, увы.
SDK для RetroBSD специально была сделана портируемой (и наверняка не на все существующие ОС) чтобы делать кросс-компиляцию, потому что на самом RetroBSD собирать не удобно.
Попробуй собрать ядро Linux на RetroBSD, или даже на OpenBSD (без GNU bitutils, gnu make, баша (там ksh), и гцц: шлангом и бздёвыми тулами с pmake). Скорее всего тебя ожидает сюрприз.
> POSIX API
Ты можешь использовать стандартную библиотеку си уровня C89 (VC не поддерживает c99), и собираться примерно одинаково всеми компиялторами, но далеко ты так не уедешь.
POSIX внезапно тоже покрывает далеко не все: начиная от сискола signal() (который в BSD и SystemV ведет себя по разному) и заканчивая epoll/kqueue в разных *nix нас ждут разные API.
Именно потому у любого крупнгого проекта есть огромные ОС-специфичные куски.
Тоже касается и сборки.
Неужели я могу просто так собрать clangом любую линуксовую и GNUшную тулу?
>Почему на винде такое возникло? Нахуя было вендорлочить?
SDK -- довольно крупная штука, и поддерживать её совместимость с разными компиляторами и OS это большая работа.
Смотри, Linux на Clang тоже не очень легко переносится
https://github.com/ClangBuiltLinux/linux/issues
И так, проблем много.
А есть ли бенефиты? Я ни одного не вижу.
Но разумеется, маркетинговое решение тут тоже есть: MS хочет, чтобы ты покупал Windows.
> Хорошо ли это?
Было бы отлично, если бы все ОС реализовывали одинаково SUS/POSIX, и все компиляторы работали бы одинаково.
Но увы...
Как это мешает сделать кросскомпиляцию?
> Тоже касается и сборки.
С каких хуёв процесс сборки надо гвоздями прибивать к конкретной ОС? Компилятору нужно лишь читать из файла, писать в файл и аллоцировать/освобождать память, и всё, нихуя ничего платформоспецифичного компилятору делать не надо. Компилятору не нужно быть завязанным на какую-то хуйню вроде COM или реестр виндовса для компиляции чего-либо.
> SDK -- довольно крупная штука, и поддерживать её совместимость с разными компиляторами и OS это большая работа.
Что именно там ОС-специфичного? Повторяю, компилятору достаточно чтения файлов, запись в файлы, выделение памяти через malloc и освобождение через free.
> Смотри, Linux на Clang тоже не очень легко переносится
Это ты вообще в другую оперу полез. Я говорю не о том, чтоб хер пойми что хер пойми каким компилятором собиралось, а чтоб компилятор X который умеет компилировать код только !!ДЛЯ!! операционки W мог это делать не только в операционке W, а вообще в любой операционке, где есть возможность читать писать файлы и выделять память на хипе. С хрена ли ты приплел тот факт, что у разных компиляторов разные расширения?
С таких, что ты не можешь скомпилировать любой код любым компилятором.
Ты не можешь взять Clang, и скомпилировать им Linux ядро "из коробки", не сделав предварительно телодвижений.
>С каких хуёв процесс сборки надо гвоздями прибивать к конкретной ОС?
Процесс сборки может быть прибит:
* к утилитам GNU (которых нет во многих ОС, пока ты их туда не поставишь)
* компилятору, которого нет на другой ОС
>Повторяю, компилятору достаточно чтения файлов
Сборка проекта состоит не только из компиляции .c файлов в объекты с последующей линковкой, но еще и хуевой кучи всего: от компиляции ресурсов, до генерации лексеров и парсеров.
На тебе жабаговно от гнушников
https://openjdk.java.net/groups/build/doc/building.html
Build Tools Requirements
* Autoconf
* GNU Make
* GNU Bash
Всё. Без этого говна ты ничего не соберешь.
>Компилятор X который умеет компилировать код только !!ДЛЯ!! операционки W мог это делать не только в операционке W
В смысле ты спрашиваешь меня, почему VisualC++ не портировали под Linux, чтобы ты там мог зачем-то собирать код под Win32API?
Да. И какое это имеет отношение к вопросу о том, почему я не могу код специально для MSVC компилировать в MSVC который работает не в винде?
> Процесс сборки может быть прибит:
> * к утилитам GNU (которых нет во многих ОС, пока ты их туда не поставишь)
Эти утилиты непереносимы (вендорлокнуты)? Ну типа, может они к systemd привязаны, и без systemd они не запускаются?
> Сборка проекта состоит не только из компиляции .c файлов в объекты с последующей линковкой, но еще и хуевой кучи всего: от компиляции ресурсов, до генерации лексеров и парсеров.
Что в этом платформоспецифичного?
> В смысле ты спрашиваешь меня, почему VisualC++ не портировали под Linux, чтобы ты там мог зачем-то собирать код под Win32API?
Бинго!
shell и make это части операционной системы (во всяком случае, в bsd). Тот факт, что приходится рядом с ними ставить еще и их GNUшные аналоги говорит нам о том, что для сборки проекта недостаточно портировать компилятор: нужно портировать и другие утилиты тоже.
Теперь смотрим, какие утилиты нужны винде:
>Что в этом платформоспецифичного?
В SDK есть .bat файлы, которые не работают на *nix по причине отсутствия там cmd.exe.
В SDK есть утилиты, использующие API операционки.
Компилятор ресурсов ``rc.exe`` импортирует user32.dll и kernel32.dll.
Наконец сам компилятор файл "cl.exe" импортирует следующие dll:
* ole32.dll
* kernel32.dll
* MSVCP140.dll (это как раз рантайм)
* ADVAPI32.dll
>Бинго!
Итого:
Чтобы портировать WinSDK и VisualC++ на Linux, там придется:
* Убрать завязку на наличие cmd.exe из SDK
* Убрать завязки на win32API (сделав свой слой абстракции, где этот функционал реализован поверх линуксовых сисколов)
Звучит как "дохуя работы", а какой в этом практический смысл я так и не понял.
Зачем собирать что-то для виндуоса на линуксе?
Отсутствие cmd.exe это наименьшая из проблем. В wine есть свой cmd который может батники запускать.
> Зачем собирать что-то для виндуоса на линуксе?
Чтобы можно было юзать билд-серверы не на винде для сборки.
Возможно можно запусьтить VisualC++ на Wine. Я не пробовал.
API винды частично закрыт, и я не уверен в стабильности этого решения:)
>Чтобы можно было юзать билд-серверы не на винде для сборки.
Зачем? Какой в этом смысл?
А в линуксе так делают, кстати? Убунту и дебиан собирают на FreeBSD и Solaris?
Допустим чтоб арендовать в AWS хуйни и там компилировать под винду не в винде.
> А в линуксе так делают, кстати? Убунту и дебиан собирают на FreeBSD и Solaris?
С FreeBSD - https://gist.github.com/bijanebrahimi/62596745808f8667c40ff91b07d9e7b8
C Solaris - https://stackoverflow.com/a/2438768
Ну и наверняка можно и из FreeBSD под Solaris, и из Solaris под FreeBSD, но есть шанс напороться на хуевый сборочный скрипт, который тебе всю малину испортит.
А на AWS нельзя поставить винду?
Просто если я виндоблядь, то у меня и админы виндобляди, и линукса не знают. Зачем плодить сущности и изучать что-то еще?
>wget https://ftp.gnu.org/gnu/binutils/binutils-2.27.tar.gz
Ну то есть начинать нужно с кучи левых сущностей?
А зачем? В чем смысл?
Если я пишу, например, игру под Direct3D, то я вообще может линукс в глаза не видел. Зачем мне про него думать?
А если я не хочу ставить винду? Нахуй ставить винду только ради компилирования хуйни под винду?
Потому что VC++ не работает под другие ОС:)
Вообще винда так работает: чтобы что-то под нее сделать, обычно нужно поставить винду.
Нахуя ставить систему с GDI чтобы сделать на ней файлопомойку, например? Или веб сервер?
Но ставят же
Кстати нахуя придумали эту поебень с ресурсами, если всю хуйню можно хранить просто как обычные данные, не внося новых сущностей?
А так то да, qt картинки просто эмбеддит как сишные массивы.
У тебя есть .exe файл с иконкой и картинками, например
Если б эта хрень была нужна только чтоб у .exe файла была иконка, я б этот вопрос не задавал.
Но там можно хоть картинки хранить, хоть что
да-да, можно задавать вопрос "а что хорошего в твоей шутке?"
Ты против ембединга иконок? не нужно так делать?
https://www.youtube.com/watch?v=LuSNjmEcVjY
Вообще, если внимательно перечитать сообщение https://govnokod.ru/27294#comment615192 то я указывал не только на проблему сборки для "проектов", вендорлокнутых на непереносимый тулчейн (тулчейн, который запускается только на винде), но и на проблемы что некая IDE хранит некую хуйню:
> "Самое главное -- макросы, инклуды, прочие опции конпелятора которые влияют на код. Вот это вот самое нужное в "проекте". Без этой инфы проще взять "ноутпад++" и не заморачиваться с "ИДЕ"."
которая делает более удобным редактирование что-то в этом "проекте", и эта хуйня работает только в этой ОС только в этой "ИДЕ", и извольте компилировать это только на винде, билдсерверы с прыщами тут не катят.
Билдсервера на прыщах и так не катят же
... то можно сделать так, чтоб работали. Или запускать через неэмулятор wine (не факт что прокатит).
> Билдсервера на прыщах и так не катят же
И это плохо
Ну ты согласен, что это много работы: отпилить всё от Win32API?
>. Или запускать через неэмулятор wine (не факт что прокатит).
Когда что-то проприетарное реверс-инженерят всегда может что-то не прокатить)
>И это плохо
Ну блин, мне тоже не нравится, что винда не POSIX. Но с этим уже ничего не сделаешь.
Маємо те, що маємо
Какое-то потепление с их стороны есть.
Потепление началось потому, что они поняли, что скоро станут не нужны.
Нахуя питонисту ебаться с виндой (где нет гуникорнов) если у него есть мак или убунта?
Нет конечно, но раньше и в виндовом нельзя было.
Но даже в худшем случае это лучше чем виртуалка. Ёбли меньше на порядок.
С новым контейнером на каждый билд оно таки чище и воспроизводимей.
Но софт любит серануть в реестр или в %LOCALAPPDATA%, и увы
Поэтому пусть сидит в одноразовом контейнере.
какой бугор ))
Хеш от пути к файлу (что логично), положения в нём (что логично) и какой-то матери.
Мне казалось, что если ты хочешь линковаться с внешними чуваками, то ты делаешь extern "C".
А что там наманглит компиляторр для статической линковки в один бинарь тебе пофиг, не?
у тебя sha пощитан от него?
Ну вот есть у тебя бинарь и его исходники. Как ты убедишься, что он из них собран?
Дебиан вон тоже на это дрочит, овер 90% пакетов байт в байт можно пересобрать.
если дата сырцов новее бинаря, то нужно его пересобрать
если нет, то нет
ты не знаешь что у тебя получится, пока не соберешь.
если ты уже собрал, то получи sha, и распостраняй бинарь и sha.
В какой момент я могу захотеть сам собрать бинарь заарнее зная что у меня получится?
Если у меня автогенеренное имя лямбды другое, то как мне это мешает?
Но ты мне не доверяешь и боишься его запускать. Тогда я даю тебе исходники. Ты их читаешь и собираешь... но получается какая-то другая хуйня, в которой весь код перемешан потому что лямбды по-другому называются. А запустить свой собранный драйвер ты толком не можешь т.к. подписать тебе его нечем. В итоге ты ни то ни другой юзать не можешь.
Тут-то ты и задумываешься, как было бы заебись, если бы бинарь всегда собирался одинаково.
хотя он конечно редкоземельный
у меня на репе лежит deb-src и deb. Ты почитал код deb-src, собрал deb, и убедился, что я не пиздун
от чего всетаки зависит имя лямды?
В gcc вроде только от контента цппшника. Анонимный неймпейс вроде от пути к файлу ещё.
если я чрутнул всё, и сырцы лежат в fakeroot , то проблемы нет
В последних студиях вроде тоже починили.
вообще есть ощущение, что крестобялди соснули
в няшной имена символов стабильны и предсказуемы
А так получается, что с одной стороны анонимная хуйня не должна торчать из своего объектника. А с другой стороны мёржить одинаковый код из хедеров то хочется, поэтому она не совсем приватная, comdat по сути.
Вот и начинается ёбля с тем как мёржить foo и foo и при этом не мёржить foo и foo.
Если найдёшь -- можешь торвальдса пригласить побухать. Он обещал проставиться.
Какой блокчейн )))
Всегда пишу
hash(hash(hash(hash(hash($var))
Настоящий PBKDF2 примерно так и работает, только там хмак вместо хеша.
Х.з., возможно хотелось более стабильное имя, чтобы даже при небольших правках не менялось. Пока ты рядом новую лямбду не добавишь.
удобно
Ты можешь паралельно распространить бинарь и собирать чтобы потом убедиться что все совпадает и использовать разданные бинарники
нахуя мне 5000 раз собирать одно и тоже?
Нахуя - чтобы на деплой тратить не час а полчаса или не два часа а час
компилировать на десяти машинах одно и тоже?
чем это быстрее?
и если Борманд утверждает, что на разных машинах у тебя разные имена лямбд, то и билд по вашему не "ррепродюсбл"
у тебя есть бинарь который раздать по сети 30 минут и сорцы которые компилировать 30 минут
ты предлагаешь его сначала собрать, потом раздать = 60 минут
я предлагаю параллельно раздать и собрать чтобы потом каждая машина смогла сверить sha бинарника и того чтобы собралось = 30 минут, компилируется только на одной машине которая зарепортит sha
идею я понял, но если Борманд утверждает, что в зависимости от машины у тебя будут разные бинари, то получается,что и собирать их придется в виртуалке?
^
you are here
Когда они уже до systemd доберутся...
Не надо было его припиливать туда.
> Ну блин, мне тоже не нравится, что винда не POSIX. Но с этим уже ничего не сделаешь.
Для компиляции никакой POSIX не нужен. Компиляция - чтение файлов, запись в файлы, выделение и освобождения памяти. Это можно и на условной DOS делать, если убрать ебнутые ограничения на имена файлов.
Ты предлагаешь юзать C89? А как делать многопроцесную компиляцию? -j4 как сделать?
"-j4" не юзает никаких pthread-ов или чего-то такого. Это просто означает, что одновременно можно запускать 4 процесса компилятора/линкера/еще-какой-то-хуйни.
Разве в c89 есть для этого API?
Я правда не знаю, могу ошибаться
Выходит, для портирования компилятора между прыщами и пиндой придется делать разный код.
И такого, я уверен, дофига: "за бесплатно" портировать не получится.
Алсо, винда же это не просто ядро, это еще туева хуча сервисов.
Захочешь ты там в SDK свой .exeшник подписать например, и тебе понадобится доступ к виндовому CryptoAPI, потому что у пользователя там лежит сертификат и ключ (в отличие от линуксов, где "openssl" это просто сторонняя тула, в винде это часть системы)
Какие сложности у тебя возникнут с написание общей обертки под разные ОС, умеющие в эту многозадачность?
> Выходит, для портирования компилятора между прыщами и пиндой придется делать разный код.
Компилятор ничего про многопоточность знать не должен, вызывать несколько экземпляров компилятора параллельно - задача сборочных скриптов
> И такого, я уверен, дофига: "за бесплатно" портировать не получится.
Приведи реальный пример
Любой код увеличивает сложность системы. Не стоит добавлять код, если он не решает никакую полезную задачу.
Задача "компилировать виндовый софт под линуксом" полезной не является к сожалению, потому что у нас пока нету ни одного реального примера такого желания от разработчика под windows.
>вызывать несколько экземпляров компилятора параллельно - задача сборочных скриптов
То есть нам еще нужно портировать и какие-то сборочные утилиты, и написать этот код в них?
>Приведи реальный пример
Ну вот нет кросс-платформенного запуска процессов.
signtool на винде умеет сходить в time server
https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool?redirectedfrom=MSDN
для работы с http у винды есть API, использующее настройки системы (прокси, аутентификацию, итд): все это придется переписывать
Да и сам Signtool завязан на CryptoAPI.
У нас - это у кого? Вот пример: - кто-то такой херней занимается, значит кому-то оно надо.
Хождение по http и всякие криптоапи - это уже не компилятор, а какая-то вспомогательная херня. Нехер было такую дикую поебень городить. Мне для компиляции хуйни через GCC не нужно никакое криптоапи и никакой http
Даже если ты технически сможешь запинать их тулчейн под прыщи (а это несложно), они тебя просто засудят нахуй за то что ты не с макакабука собирал.
Вендор лок такой вендор лок))
шланг не сложно, а как ты будешь какие нить сториборды компилировать?
там же наверняка проприетарные тулы на Mach-O с кучей зависимостей?
А что это? Нам чисто сишку надо было, и то не разрешили. Шланга и библиотек вполне хватило бы.
а вам нужна была corefoundation, или хватило бы тока bsdшных api?
Если тока BSD, то может можно было как-то DarwinBSD собрать?
В с89 есть функция system(), только там надо ждать завершение того запущенного процесса, так что второй параллельный процесс ей не породить.
В линуксах у тебя чуть ли не в сисколе есть argv, а в винде это строка, и их нужно правильно склеить:)
А еще ты захочешь наверное чтобы новый процесс наследовал от тебя какие-то дескрипторы, или чтобы его завершения можно было ожидать (типа wait()), или проложить с ним какой-то pipe, чтобы общаться.. и все это нифига не портабельно на винду без кастомного кода
В винде это строка если у тебя https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-winmain
Обычный main там тоже есть, и работает он как обычно
https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=msvc-160
https://devblogs.microsoft.com/oldnewthing/20100917-00/?p=12833
боль
https://web.archive.org/web/20190109172835/https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/
Хмм... а зачем это компилятору?
а как мне знать, что они завершились?
Это уже проблема не компилятора. Это проблема той штуки, которая их (процессы компилятора) запускает. И в самом компиляторе с этим ничего делать не надо.
ну блядь, в 1995-м году MS вообще не думал, что они как-то будут с юниксом серьезно соприкасаться
Нахуя было вообще брать VMS вместо Unix для NT?
Я бы с радостью отменил Windows, и заменил бы его на что-то типа Mac OS (которая SUS), чтобы не держать в голове по два вида каждой сущности, но увы
а проекты визуалки ты можешь открывать и в других IDE, как и икскодовские
Функция аналогичным образом описывает свой контракт на входе. Если тупла не кастанулась -- значит каких-то утверждений не хватило.
З.Ы. Что-то я боюсь PoC этой хуйни пилить, как бы дьявола не призвать.
Хорошо, если так.
Мечтаю о таком для джвы, чтобы например функции с пометкой @Slow нельзя было вызвать из треда, обрабатывающего гуйные события (функции с пометкой @EDT, например)
В SDK вроде тоже есть аннотации про in/out и связи между размером и поинтером, но я не уверен что везде.
в требовании
IRQL PASSIVE_LEVEL
значит ли это, что я не могу позвать её из обработчика прерывания?
В MSDN я не вижу на ней никакой аннотации, но может быть она есть в .h файле
или это вот то самое IrqlPsPassive ?
Саму аннотацию в хедере поищи.
Круто, что такая штука есть
зы
нашел
вот это
_IRQL_requires_max_(PASSIVE_LEVEL)
?
Потому что Walter Oney в книжке про WDM про это ничего не писал.
серый котейка в ботинок ссал