Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Effect of CPP tags Date: Sun, 31 Dec 2023 18:31:00 -0800 Organization: A noiseless patient Spider Lines: 95 Message-ID: <867cktu6mz.fsf@linuxsc.com> References: <86bka5uda0.fsf@linuxsc.com> <874jfxvqi0.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="4ad5b29cc5222e274263b40ba81c3fd0"; logging-data="2026768"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+TNWr6wy5ysMZ4Nergan6bajN0+TpXzXU=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:HjdpEMpzV4a7hjD50E2WQiNDoKk= sha1:BvlFuuJg9jCCc2djTIegXaLnw58= Xref: csiph.com comp.lang.c:379727 Keith Thompson writes: > Tim Rentsch writes: > >> Janis Papanagnou writes: >> >>> This is a CPP question that arose last month. It's not about an >>> actual issue with the software, just out of curiosity and to be sure >>> it works reliable (it seemingly does). >>> >>> In a C99 program on Linux (Ubuntu) I intended to use usleep() and >>> then also strnlen(). >>> >>> When I added usleep() and its include file I got an error and was >>> asked to define the CPP tag '_BSD_SOURCE'. I did so, and because I >>> wanted side effects of that tag kept as small as possible I >>> prepended it just before the respective #include and put it at the >>> end of my #include list >>> >>> ...other #includes... >>> #define _BSD_SOURCE >>> #include >>> >>> But as got obvious *that* way there had been side-effects and I >>> had to put the tag at the beginning of all include files (which >>> astonished me) >>> >>> #define _BSD_SOURCE >>> #include >>> ...other #includes here... >>> >>> For the strnlen() function I needed another CPP tag, '_GNU_SOURCE'. >>> So now I have both CPP tag definitions before the includes >> >> I second the recommendations of Lowell Gilbert and others not to >> define _BSD_SOURCE or _GNU_SOURCE (especially not _GNU_SOURCE) >> but instead seek alternatives, which are readily available for >> the two functionalities being sought in this case. >> >>> #define _GNU_SOURCE /* necessary for strnlen() in string.h */ >>> #define _BSD_SOURCE /* necessary for usleep() in unistd.h */ >>> ...all #includes here... >> >> For strnlen(), put an inline definition in a header file: >> >> #ifndef HAVE_strnlen_dot_h_header >> #define HAVE_strnlen_dot_h_header >> >> #include >> >> static inline size_t >> strnlen( const char *s, size_t n ){ >> extern void *memchr( const void *, int, size_t ); >> const char *p = memchr( s, 0, n ); >> return p ? (size_t){ p-s } : n; >> } >> >> #include >> >> #endif >> >> Disclaimer: this code has been compiled but not tested. > > strnlen() is specified by POSIX. It might make sense to > re-implement it if your code needs to work on a non-POSIX system > (that doesn't also provide it). Why would you want to do so > otherwise? I'm trying to provide a helpful answer to the person I was responding to, not espouse a philosophical viewpoint. Why do you feel the need to start a style debate? > memchr() is declared in . Why would you duplicate its > declaration rather than just using `#include `? I had a specific reason for writing the code the way I did. It wasn't important to explain that so I didn't. >> For usleep(), define an alternate function usnooze(), to be used >> in place of usleep(). In header file usnooze.h: > > [snip] > > If your code doesn't need to be portable to systems that don't > provide usleep(), you can just use usleep(). If it does, its > probably better to modify the code so it uses nanosleep(). Not everyone agrees with that opinion. Again, I'm just trying to provide an answer helpful to OP, not advance an agenda. Like I said in the part of my posting that you left out, I don't want to get involved in a style war. If OP wants to modify his code to use nanosleep(), I'm fine with that. If want wants to keep using usleep() or switch to using usnooze(), I'm fine with that too. I think it's more important in this case to provide options than to try to change someone's point of view.