Узнать ОС в C

сообщение модераторам: я предлагаю банить юзеров которые не могут воспользоваться гуглом

с чего ты взял что ему нужно не в рантайме?

А почему линукс false?

Поидее наоборот надо. Если Win32 функция проверяющая ОС должна возвращать ложь.

А как ты линуксовый бинарник будешь запускать на виндувс?

http://www.i-programmer.info/news/177-windows-8/9591-run-linux-binaries-on-wi...

скорее наоборот

bool  os()
{
#ifndef _WIN32
  return true;
#else
  return false;
#endif
}

бсд-ешники негодуют
на лицо сокорбление чувств и меньшинств (еще 100500 осей)

+ к бану

не проще 2 бинаря собрать будет, не?

я не оскорбился)

Какая разница, если в рантайме всегда 1 ОС.

Не учи плохому, это только в POSIX взлетит.

#include <stdio.h>
FILE *f = fopen("/usr/lib/systemd", "r");
if (f == NULL) {
        return true;
} else {
        fclose(f);
        return false;
}

я чуть-чуть упрощу, так читать, на мой взгляд, приятнее:

bool is_windows (void) {
    if (access("/usr/lib/systemd", F_OK) == 0) return true;
    return false;
}

А что если systemd расположен в каком-нибудь нестандартном префиксе, как, скажем, в nixos?

Ну уж если упрощать, то почему бы не return access("/usr/lib/systemd", F_OK) == 0;?

Погугли, на форумах легко найдёшь http://forum.sources.ru/index.php?showtopic=294285

А что если systemd расположен в каком-нибудь нестандартном префиксе, как, скажем, в nixos?

ищем в $PATH, как же еще!

Ну уж если упрощать, то почему бы не return access(«/usr/lib/systemd», F_OK) == 0;?

не думаю что это хорошая идея
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdbool.h.html

При чём тут описание stdbool.h?

При том, что тип возвращаемого значения функции bool. Следовательно, во имя следованию стандарту логично явно использовать макросы true и false.

Согласно этому же стандарту, значения, возвращаемые операторами сравнения, легко и непринуждённо приводятся к bool, поэтому никакого смысла в этом нет.

А если под вайном, что надо возвращать?

я понимаю что в С 0 это неявно false, а не0 - true, но когда в ПО вводят спец. хидер для этого - им стоит пользоваться

я успел увидеть 0 и !0 ад в реальных проектах, а также грабли, которые из них вытекают.

Не понимаю С разработчиков, которые скептически относятся к stdbool и iso646 только из-за того, что «мы так привыкли».

Осталось выяснить, что делать тем, у кого нет udev.

access(«/lib/ld-linux.so.2», R_OK)

Сравнение с нулём — это про возвращаемое значение функции, которое int. Мне наплевать, каково низкоуровневое представление булов, но я точно знаю, что (bool)(a == 0) равен true тогда и только тогда, когда a, как ни странно, равно нулю. А выражения вроде if (expr) return true; else return false; уж точно не добавляют коду выразительности.

Это тоже не работает в дистрибутивах, использующих нестандартный префикс.

выражения вроде if (expr) return true; else return false; уж точно не добавляют коду выразительности

Я понял. Ты один из «этих».

Вот и модератор пришел попетросянить

Это тоже не работает в дистрибутивах, использующих нестандартный префикс.

И что? Всё, что можно предложить ТС - это эвристики. Понятно, что для каждой из них можно придумать условия, когда она сфейлит. Например, нестандартный префикс (GoboLinux, ага).

Не понимаю С разработчиков, которые скептически относятся к stdbool и iso646 только из-за того, что «мы так привыкли».

Просто преимущества stdbool не очевидны.

А всё потому, что их нет. D:

Страшно взять что-то новое и иногда подумать головой. Люди меньше всего хотят перемен, и это нормально.

Страшно взять что-то новое и иногда подумать головой. Люди меньше всего хотят перемен, и это нормально.

Ну хорошо, ты подумал, тебе не страшно, ты уже взял и освоил. Так расскажи нам, зачем?

Ну хорошо, ты подумал, тебе не страшно, ты уже взял и освоил. Так расскажи нам, зачем?

Удобно. Читаемо. Красиво.
А в результате тратится меньше времени разработчика.

iso646 — плохая идея, хотя бы из-за свойств препроцессора.

хотя бы из-за свойств препроцессора

каких именно? можно аргументацию, пожалуйста?

А в результате тратится меньше времени разработчика.

Меньше времени тратится, когда программист более высокоуровневые языки использует, а не когда определеляются бесполезные макросы. Что касается stdbool.h, то это лишь косметическое изменение.

Всякие and и xor будут подставляться не только тогда, когда они использованы в качестве операторов.

Меньше времени тратится, когда программист более высокоуровневые языки использует

А с низкоуровневыми, значит, тратится не меньше?

определеляются бесполезные макросы

Я всё-таки хотел бы услышать аргументацию бесполезности макросов, которые вошли в стандарт, а не повторное выражение твоего мнения.

Всякие and и xor будут подставляться не только тогда, когда они использованы в качестве операторов.

Можно пример, пожалуйста?

Правильно ли я понял, что

bool cmp(int a, int b) {
  if (a < b) return true;
  return false;
}

bool cmp(int a, int b) {
  return a < b;
}

// Речь о Си.

#include <stdbool.h>
#include <iso646.h>

bool and = true; // whoops!

удобнее, читаемее и красивее, чем

Да.

Бесполезны они по той причине, что не имеют преимуществ над обычными операторами.

bool and = true; // whoops!

А чё сразу не

int sizeof = 3;

Бесполезны они по той причине, что не имеют преимуществ над обычными операторами.

О преимуществах я уже рассказал. Реальных примеров, при которых преимущество превращается в тлен я не увидел.

Например, нестандартный префикс (GoboLinux, ага)

Пользователи GoboLinux в любом случае должны страдать, но nixos-богам приходится потом патчить софт, полагающийся на абсолютные пути. «Условия, когда она сфейлит», зависят от формальной постановки задачи. Если человеку нужно узнать, есть ли у него посиксные системные вызовы (или зачем там ещё ему может понадобиться знать ОС — какие слеши использовать и т.п.), то есть способы сделать это лучше.