Здравствуйте, pagid, Вы писали:

N>>Например, берём Unix API:
N>>int open(аргументы);
N>>реально два значения — дескриптор и код ошибки (который поступает в errno).
P>Тут есть своя логика, примитивная конечно.
P>Признак ошибки -1 в возвращаемом значении, если ошибки нет, то её код не нужен совсем.

Это просто такой стиль проекции ответа {ok, Handle} | {error, Error}.
Точно так же как значение NULL для указателя (Хоар плачется, что это была ошибка, но на момент введения это было отличным выходом).
И это не единственный вариант стиля.
Например, возврат 0 из read() это вариант показать ошибку EOF. Просто EOF как бы принято считать не совсем ошибкой, потому оно не выделяется.
А вот в раннем SunOS nonblocking I/O был флаг FIOASYNC, который давал при отсутствии данных в данный момент — 0 вместо {-1, EAGAIN}, и путался с честным EOF — из-за чего его и отменили.
А могли сделать наоборот — 0 как код ошибки, а EOF внести в errno. Тоже метод, хоть и менее практично.

N>>int pipe(int fildes[2]);
N>>три значения — два дескриптора и код ошибки.
N>>int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
N>>три выходных — код ошибки, сокет и адрес.
N>>И так далее.
N>>Windows? То же самое: у до чёрта функций код ошибки передаётся боковым каналом, его надо доставать через GetLastError(). И аналог такого accept() есть, и многое другое.

P>Это все забавно, но что получается, что языкам, где не предусмотрено возвращение нескольких значений путь в эту новую "правильную" ОС с "правильными" системными вызовами будет закрыт? Или придется лепить страшные костыли.

Придётся лепить ровно такие же костыли, как и сейчас: заполнение нескольких раздельных значений по указателям, заполнение структуры по указателям, возврат структуры явным образом (на уровне конвенции превращающемся опять же в указатель на структуру). Ничего нового.

Здравствуйте, pagid, Вы писали:

N>>Например, берём Unix API:
N>>int open(аргументы);
N>>реально два значения — дескриптор и код ошибки (который поступает в errno).
P>Тут есть своя логика, примитивная конечно.
P>Признак ошибки -1 в возвращаемом значении, если ошибки нет, то её код не нужен совсем.

Это просто такой стиль проекции ответа {ok, Handle} | {error, Error}.
Точно так же как значение NULL для указателя (Хоар плачется, что это была ошибка, но на момент введения это было отличным выходом).
И это не единственный вариант стиля.
Например, возврат 0 из read() это вариант показать ошибку EOF. Просто EOF как бы принято считать не совсем ошибкой, потому оно не выделяется.
А вот в раннем SunOS nonblocking I/O был флаг FIOASYNC, который давал при отсутствии данных в данный момент — 0 вместо {-1, EAGAIN}, и путался с честным EOF — из-за чего его и отменили.
А могли сделать наоборот — 0 как признак ошибки вместо реального ответа, а EOF внести в errno. Тоже метод, хоть и менее практично.

N>>int pipe(int fildes[2]);
N>>три значения — два дескриптора и код ошибки.
N>>int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
N>>три выходных — код ошибки, сокет и адрес.
N>>И так далее.
N>>Windows? То же самое: у до чёрта функций код ошибки передаётся боковым каналом, его надо доставать через GetLastError(). И аналог такого accept() есть, и многое другое.

P>Это все забавно, но что получается, что языкам, где не предусмотрено возвращение нескольких значений путь в эту новую "правильную" ОС с "правильными" системными вызовами будет закрыт? Или придется лепить страшные костыли.

Придётся лепить ровно такие же костыли, как и сейчас: заполнение нескольких раздельных значений по указателям, заполнение структуры по указателям, возврат структуры явным образом (на уровне конвенции превращающемся опять же в указатель на структуру). Ничего нового.