Size: a a a

2021 April 30

c

codingteam@cjr in codingteam
Minoru
@insert_reference_here: а что там с CloudFlare Pages? ^_^
источник

t

ttldtor in codingteam
а у нас лапки и учесть мы это не можем
источник

D

Devel29A in codingteam
Недостаток яиц просто
источник

А⚙

Антон ⚙️ in codingteam
Ааааатстань, мне не до этого
источник

D

Devel29A in codingteam
Ждут второго пришествия условного Штольмана, который просто сделает и пошлет остальных в жопы
источник

t

ttldtor in codingteam
точнее, это даже не Oppo, а BBK Разве для них сяоми штампует?
источник

t

ttldtor in codingteam
ну да. Просто берёшь и делаешь.
источник

c

codingteam@cjr in codingteam
Minoru
@insert_reference_here: ок ._.
источник

💮

💮 in codingteam
Мне кажется, ничего менять не нужно и никакой проблемы нет.

Надо считать setenv как unsafe, а getenv как safe.
Да, unsafe-код может ломать safe-код даже после выхода из блока unsafe.
Делаешь setenv через FFI? ССЗБ.

В программе нужно сделать setenv()? Скорее всего, в твоей программе что-то не так, и чинить надо её, а не libc.

Иначе можно докатиться до того что говорить что slice.get — это unsound потому что unsafe-код из другого потока может какой угодно буфер попортить.
источник

c

codingteam@cjr in codingteam
Minoru
> Надо считать setenv как unsafe, а getenv как safe.

разумно

> Делаешь setenv через FFI? ССЗБ.
> В программе нужно сделать setenv()? Скорее всего, в твоей программе что-то не так, и чинить надо её, а не libc.

не согласен. Я не понимаю, почему не дать людям более безопасный интерфейс. Тут же нет никаких фундаментальных проблем, не дающих getenv вернуть копию вместо указателя на оригинал. Ну, да, придётся ещё и ошибки malloc возвращать, но это меньшая из бед
источник

c

codingteam@cjr in codingteam
Minoru
но твой вопрос про «а где это реально нужно?» очень хороший. Без ответа на него действительно не имеет смысла рассуждать дальше
источник

💮

💮 in codingteam
Даже если ты дашь безопасный интерфейс, то старый код который может использовать environ или getenv никуда не денется. А, значит, делать setenv в многопотоке по прежнему нельзя.

После этого можно говорить «да, бомбанёт, но бомбанёт-то не в моём коде», но что-то это такая себе выгода, КМК.
источник

💮

💮 in codingteam
Забавный факт: помимо непотокобезопасной глобальной мапы string→string (aka environ), в позиксе ещё есть крайне сомнительной нужности глобальная мапа string→void* (man 3 hsearch).
источник

c

codingteam@cjr in codingteam
Minoru
о, про environ я не знал. Видимо, придётся тот лок, что внутри setenv и (будущего) getenv_s, тоже делать глобально доступным, чтобы пользователи environ могли его брать
источник

c

codingteam@cjr in codingteam
Minoru
> После этого можно говорить «да, бомбанёт, но бомбанёт-то не в моём коде», но что-то это такая себе выгода, КМК.

согласен, но ситуация ведь будет все равно лучше, чем сейчас. Сейчас получается, что getenv и setenv надо синхронизировать, но средств для этого нет. Так хотя бы средства будут
источник

c

codingteam@cjr in codingteam
Minoru
хотя этот спор я, похоже, проигрываю :)
источник

c

codingteam@cjr in codingteam
Minoru
про hsearch я тоже не знал. Дичь
источник

K

Kerrigan in codingteam
она глобальная на процесс или на всё?
источник

💮

💮 in codingteam
На процесс.
источник

K

Kerrigan in codingteam
кого-то задолбало тягать с собой хешмапы или писать новую каждый раз
источник