Tag: posix

如何以可移植的方式检查C ++中是否存在文件？

目前，我使用此代码检查Windows和POSIX兼容的操作系统（Linux，Android，MacOS，iOS，BlackBerry 10）上是否存在文件： bool FileExist( const std::string& Name ) { #ifdef OS_WINDOWS struct _stat buf; int Result = _stat( Name.c_str(), &buf ); #else struct stat buf; int Result = stat( Name.c_str(), &buf ); #endif return Result == 0; } 问题： 这段代码有什么缺陷吗？ （也许是一个无法编译的操作系统） 是否可以仅使用C / C ++标准库以真正可移植的方式进行？ 如何改进？ 寻找规范的例子。

一旦pthread_barrier_wait返回，屏障怎么可以破坏？

这个问题基于： 什么时候摧毁pthread屏障是否安全？ 和最近的glibc错误报告： http://sourceware.org/bugzilla/show_bug.cgi?id=12674 我不确定在glibc中报告的信号量问题，但据推测，一旦pthread_barrier_wait返回，它应该是有效的，以便根据上述链接问题消除障碍。 （通常，获得PTHREAD_BARRIER_SERIAL_THREAD的线程或已经认为自己对屏障对象“负责”的“特殊”线程将是销毁它的那个。）我能想到的主要用例是当使用屏障时同步新线程在创建线程堆栈上使用数据，防止创建线程返回，直到新线程使用数据为止; 其他障碍可能具有与整个程序相同的生命周期，或由其他一些同步对象控制。 在任何情况下，只要pthread_barrier_wait在任何线程中返回，实现如何确保屏障的破坏（甚至可能取消映射它所驻留的内存）都是安全的？ 似乎尚未返回的其他线程需要检查屏障对象的至少某些部分才能完成其工作并返回，就像在上面引用的glibc错误报告中一样， sem_post必须检查服务员计数后调整了信号量值。

如何检索C / Linux上的处理器数量？

我正在编写一个小型C应用程序，它使用一些线程来处理数据。 我希望能够知道某台机器上的处理器数量，而不使用system（）和小脚本。 我能想到的唯一方法是解析/ proc / cpuinfo 。 任何其他有用的建议？

如何将多个参数传递给C中的线程

我试图将两个参数传递给C中的一个线程。我创建了一个数组（大小为2），并试图将该数组传递给线程。 这是将多个参数传递给线程的正确方法吗？ // parameters of input. These are two random numbers int track_no = rand()%15; // getting the track number for the thread int number = rand()%20 + 1; // this represents the work that needs to be done int *parameters[2]; parameters[0]=track_no; parameters[1]=number; // the thread is created here pthread_t server_thread; int server_thread_status; //somehow pass […]

有没有可以使用libc中的函数fma的情况？

我遇到这个页面 ，发现有一个奇怪的浮动乘法加法函数fmaf和fmaf 。 它说结果是这样的： (x * y) + z #fma(x,y,z) 并且值是无限精度并且对结果格式进行一次舍入 。 然而，AFAICT我以前从未见过这样的三元手术。 所以我想知道这个function的cumstom用法是什么。

使用ssize_t vs int

码 我有一个函数，我可以用以下四种方式之一编写： int do_or_die(int retval); int do_or_die(ssize_t retval); ssize_t do_or_die(int t retval); ssize_t do_or_die(ssize_t retval); 然后，它将使用这两种方式调用库函数： written = do_or_die(write(…)); // POSIX write returns ssize_t printed = do_or_die(printf(…)); // printf returns int 问题 我应该使用哪种原型？ 我应该给written和printed什么类型？ 我想拥有最强大和标准的代码，同时仍然只有一个do_or_die函数。 我在这种情况下使用C99，但如果C11的答案不同，那么我也想知道这一点，以备将来使用。

为什么在Mac OS X上不推荐使用sem_init（），sem_getvalue（），sem_destroy（） – 以及取代它们的原因是什么？

当我使用POSIX sem_init()函数编译程序时，我得到一个编译警告（错误，因为我通常使用-Werror ），当我使用GCC 4.9在Mac OS X 10.10.1（Yosemite）上编译时，该函数已被弃用。 1或来自XCode 6.1.1的Clang（ Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) ）的版本。 快速浏览一下/usr/include/sys/semaphore.h就会发现该函数在声明后确实有一个__deprecated标记， sem_getvalue()和sem_destroy() 。 问题： 鉴于POSIX规范中没有任何弃用的暗示，为什么在Mac OS X上将这三个函数单独列为已弃用？ 鉴于它们已被弃用，替代品是什么，为什么替代品更受欢迎？ （ 我确实首先检查了Ask Different ;没有问题标记c ，也没有问题询问已弃用的系统调用 – 只有程序。 ）

如何用C转换UTC到当地时间？

这是一个简单的问题，但解决方案似乎远非简单。 我想知道如何从UTC转换为本地时间。 我正在寻找一种标准的C解决方案，或多或少保证可以在任何位置的任何计算机上工作。 我仔细阅读了以下链接，但我找不到解决方案： 在C中将包含localtime的字符串转换为UTC 在C / C ++中在本地时间和GMT / UTC之间转换 我尝试了很多变体，例如（datetime是一个带有时间和日期的字符串，以UTC表示）： strptime(datetime, “%A %B %d %Y %H %M %S”, tp); strftime(printtime, strlen(datetime), “%A %B %d %Y %H %M %S”, tp); 要么 strptime(datetime, “%A %B %d %Y %H %M %S”, tp); lt=mktime(tp); printtime=ctime(&lt); 无论我尝试什么，printtime最终都与UTC相同。 编辑11-29-2013 ：基于下面“R”的非常有用的答案，我终于开始创建一个工作示例。 我发现它在我测试它的两个时区中正常工作，CET和PST： #include #include #include long long diff_tm(struct tm *a, […]

既然我们有snprintf，为什么我们没有snscanf？

我有snprintf ，它可以避免缓冲区溢出，但为什么没有名为snscanf函数？ 码： int main() { char * src = “helloeveryone”; char buf1[5]; sscanf(src,”%s”,buf1); // here is a array out of bounds } 所以，我认为还需要一个snscanf 。 为什么我们只有snprintf ？

是否有任何表现良好的POSIX间隔定时器？

受到最后一个闰秒的启发，我一直在使用POSIX调用探索计时（特别是间隔计时器）。 POSIX提供了几种设置计时器的方法，但它们都有问题： sleep和nanosleep sleep – 这些都是在被信号中断后重新启动，并引入时钟偏差。 你可以通过一些额外的工作来避免一些但不是全部的这种偏差，但这些function使用的是实时时钟，所以这并非没有陷阱。 setitimer或更现代的timer_settime被设计为间隔定时器，但它们是每个进程，如果你需要多个活动定时器，这是一个问题。 它们也不能同步使用，但这不是什么大问题。 与clock_nanosleep使用时， clock_gettime和clock_nanosleep似乎是正确的答案。 clock_nanosleep支持绝对超时，因此您可以只是睡眠，增加超时，然后重复。 在中断之后也很容易重启。 不幸的是，这些function可能也是特定于Linux的：在Mac OS X或FreeBSD上不支持它们。 pthread_cond_timedwait在Mac上可用，并且可以作为一个kludgy解决方案使用gettimeofday ，但在Mac上它只能与实时时钟一起使用，因此当系统时钟设置或闰秒发生时它会受到不良行为的影响。 我缺少一个API吗？ 是否有一种合理的可移植方式在类UNIX系统上创建表现良好的间隔计时器，或者这总结了今天的状态？ 通过良好的行为和合理的便携性，我的意思是： 不容易出现时钟偏差（当然，减去系统时钟自身的偏差） 适应正在设置的系统时钟或发生闰秒 能够在同一个过程中支持多个计时器 至少可在Linux，Mac OS X和FreeBSD上使用 关于闰秒的注释 （响应R ..的回答 ）： POSIX天的长度恰好是86,400秒，但现实世界的日子很少会更长或更短。 系统如何解决这种差异是由实现定义的，但闰秒通常与前一秒共享相同的UNIX时间戳。 另请参见： 闰秒以及如何处理它们 。 Linux内核闰第二个错误是在将时钟设置为秒后未能进行内务处理的结果： https ： //lkml.org/lkml/2012/7/1/203 。 即使没有那个错误，时钟也会向后跳一秒钟。