Re: gethostname vs pread/pwrite in Linux

From

Valentin Nechayev ()

To

Igor Sysoev ()

Date

2003-06-05T14:11:30Z

Area

RU.UNIX.PROG

From: Valentin Nechayev <netch@segfault.kiev.ua>

>>> Igor Sysoev wrote: 

IS> Спасибо за советы. Решил воспользоваться -D_GNU_SOURCE.
IS> Но есть такой вопрос - какой тайный смысл этих _BSD_SOURCE, _GNU_SOURCE и
IS> _XOPEN_SOURCE ?

Начинаются-то они с _POSIX_SOURCE. Идея такая: в системе может быть что
угодно, но если она соответствует Posix'у, то программе при определении
_POSIX_SOURCE должно быть доступно только то, что в Posix, и не более.
Цель - обеспечение переносимости - заставляем компилироваться с _POSIX_SOURCE
и тогда можем быть уверены, что программа переедет без проблем на другую
систему, тоже соответствующую Posix'у. Потом вместо _POSIX_SOURCE
назначили _POSIX_C_SOURCE, _POSIX2_C_SOURCE и так далее, _XOPEN_SOURCE...

Но это ограничительные определения. А есть, наоборот, разрешительные.
_GNU_SOURCE для glibc - команда включать всё, _BSD_SOURCE - включать
комплект BSD'шных определений, и так далее.

За деталями лучше всего смотреть: info libc 'Feature test macros'.
Соотношения между тем, что включается, а что исключается, достаточно
туманны.

IS> Скажем, в случае _FILE_OFFSET_BITS, _REENERANT или даже _LARGEFILE_SOURCE
IS> мне понятен физических смысл этих определений, а вот _GNU_SOURCE - нет.
IS> Что плохого в том, что будет доступно определение pread/pwrite ?

См. выше.

P.S. Ну ты дискуссию во freebsd-arch помнишь недавнюю насчёт проблемы
включения видимости символов в libc без их маскировки? (Тема:
`Hiding' libc symbols)
Это я к тому, что не всё решается только видимостью на этапе компиляции.


-netch-
--- ifmail v.2.15dev5
 * Origin: Dark side of coredump (2:5020/400)