On Sun, May 12, 2019 at 3:48 AM Antonio Diaz Diaz <[email protected]> wrote: > > Hi Rosen, > > Rosen Penev wrote: > > Build log of the issue: > > https://downloads.openwrt.org/snapshots/faillogs/arc_arc700/packages/gddrescue/compile.txt > > > > I've tried including extra headers but it doesn't work. Only thing > > that works is to use the plain variants of fgetc, feof, and ferror. > > > >> From looking at the uClibc-ng source code, I can't find a good reason > > why this is not working. Interestingly enough, the other ones like > > std::fopen work. > > It seems that uClibc-ng is defining fgetc, fputc, feof, and ferror as > macros and not including them in std. > > From the C++ 2003 standard: > > "Except as noted in clauses 18 through 27, the contents of each header > cname shall be the same as that of the corresponding header name.h, as > specified in ISO/IEC 9899:1990 Programming Languages C (Clause 7), or > ISO/IEC:1990 Programming Languages--C AMENDMENT 1: C Integrity, (Clause > 7), as appropriate, as if by inclusion. In the C++ Standard Library, > however, the declarations and definitions (except for names which are > defined as macros in C) are within namespace scope (3.3.5) of the > namespace std." > > But these four functions do not seem to be defined as macros in C. > > IMO this is a bug in uClibc-ng Even so, it might still make sense to work around it.
For now, I've disabled building gddrescue with uClibc-ng in OpenWrt. > (maybe caused by lack of clarity in the > C++ standard), because even the C functions that are alowed to be > defined as macros (putc, getc) should be included in std for > consistency. Just imagine the chaos if std::getc were defined or > undefined depending on how it is implemented. > > From the C 1999 standard: > > "The getc function is equivalent to fgetc, except that if it is > implemented as a macro, it may evaluate stream more than once, so the > argument should never be an expression with side effects." > > Note that getc is allowed, not required, to be implemented as a macro. > > > Best regards, > Antonio. _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
