No C99 compliant functions are used

[hiyuh]

SSIA.

$ make
...
src/driver/c_driver.c: In function ‘run_external_preprocessor’:
src/driver/c_driver.c:368:2: warning: implicit declaration of function ‘popen’ [-Wimplicit-function-declaration]
  FILE *f = popen(commandline, "r");
  ^
src/driver/c_driver.c:368:12: warning: initialization makes pointer from integer without a cast
  FILE *f = popen(commandline, "r");
            ^
CC build/debug/./src/parser/token.o
src/driver/driver.c: In function ‘close_input’:
src/driver/driver.c:136:3: warning: implicit declaration of function ‘pclose’ [-Wimplicit-function-declaration]
   res = pclose(unit->input) == EXIT_SUCCESS;
   ^
...
src/parser/preprocessor.c: In function ‘update_timestamp’:
src/parser/preprocessor.c:2798:3: warning: implicit declaration of function ‘fileno’ [-Wimplicit-function-declaration]
   int   const fd = fileno(file);
   ^
LD build/debug/cparser

according to glibc man pages,

• using popen() and pclose() requires stdio.h and _POSIX_C_SOURCE >= 2 || _XOPEN_SOURCE || _BSD_SOURCE || _SVID_SOURCE.
• using fileno() requires stdio.h and _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE.
  note, src/parser/preprocessor.c does not include stdio.h explicitly.

also top Makefile has hardcoded -std=c99 -pedantic.

$ grep -e '-std=c99 -pedantic' -n Makefile
21:CFLAGS += -Wall -W -Wstrict-prototypes -Wmissing-prototypes -std=c99 -pedantic

P.S.
i don't know about cparser coding convention correctly.
but using pedantic standard explicitly by default and breaking them looks simply uncool.

[hiyuh]

ok, i'm wrong a bit.
it looks this issue relates src/driver/enable_posix.h is broken on cygwin,
b/c it defines _WIN32.

[MatzeB]

I guess you can experiment with "#if defined(_WIN32) && !defined(CYGWIN)" instead of #ifdef _WIN32

[hiyuh]

sadly, it doesn't work even if i modified to use defined(__WIN32) && !defined(__CYGWIN__).
after seeing cygwin bundled stdio.h (maybe, it comes from newlib?),
i found it looks omitting decls of popen(), pcolse() and fileno() if __STRICT_ANSI__.

/*
 * Routines in POSIX 1003.1:2001.
 */

#ifndef __STRICT_ANSI__
#ifndef _REENT_ONLY
FILE *  _EXFUN(fdopen, (int, const char *));
#endif
int _EXFUN(fileno, (FILE *));
int _EXFUN(getw, (FILE *));
int _EXFUN(pclose, (FILE *));
FILE *  _EXFUN(popen, (const char *, const char *));
int _EXFUN(putw, (int, FILE *));
void    _EXFUN(setbuffer, (FILE *, char *, int));
int _EXFUN(setlinebuf, (FILE *));
int _EXFUN(getc_unlocked, (FILE *));
int _EXFUN(getchar_unlocked, (void));
void    _EXFUN(flockfile, (FILE *));
int _EXFUN(ftrylockfile, (FILE *));
void    _EXFUN(funlockfile, (FILE *));
int _EXFUN(putc_unlocked, (int, FILE *));
int _EXFUN(putchar_unlocked, (int));
#endif /* ! __STRICT_ANSI__ */

so i'm getting to being not sure it is still valid cparser's issue...
note, i'm asking in cygwin ML, see https://cygwin.com/ml/cygwin/2015-12/msg00140.html.

update1: above snippet had visible tabs.
update2: add note for my post in cygwin ML.

[MatzeB]

Looks like cygwin ignores posix feature test macros if STRICT_ANSI is defined, that is very surprising behaviour.
I changed the cparser Makefile to not use -std=c99 anymore for cygwin to avoid STRICT_ANSI being defined.

• Matthias

On Dec 11, 2015, at 11:37 PM, KIMURA Masaru notifications@github.com wrote:

sadly, it doesn't work even if i modified to use defined(WIN32) && !defined(__CYGWIN).
after seeing cygwin bundled stdio.h (maybe, it comes from newlib?),
i found it looks omitting decls of popen(), pcolse() and fileno() if STRICT_ANSI.

/*

• Routines in POSIX 1003.1:2001.
  */

#ifndef STRICT_ANSI
#ifndef _REENT_ONLY
FILE _>-_EXFUN(fdopen, (int, const char *));
#endif
int>_EXFUN(fileno, (FILE *));
int>_EXFUN(getw, (FILE *));
int>_EXFUN(pclose, (FILE *));
FILE * _EXFUN(popen, (const char *, const char *));
int>_EXFUN(putw, (int, FILE *));
void _EXFUN(setbuffer, (FILE *, char *, int));
int>_EXFUN(setlinebuf, (FILE *));
int>_EXFUN(getc_unlocked, (FILE *));
int>_EXFUN(getchar_unlocked, (void));
void>---_EXFUN(flockfile, (FILE *));
int>_EXFUN(ftrylockfile, (FILE *));
void>---_EXFUN(funlockfile, (FILE *));
int>_EXFUN(putc_unlocked, (int, FILE *));
int>EXFUN(putchar_unlocked, (int));
#endif / ! STRICT_ANSI */
so i'm getting to being not sure it is still valid cparser's issue...

—
Reply to this email directly or view it on GitHub #10 (comment).

[earnie]

POSIX != STRICT_ANSI

The two are entirely different. If STRICT_ANSI is defined then you need to follow the ANSI standard document and not the POSIX one. The macro STRICT_ANSI means do not define any functions outside of the standard document for ANSI.

[MatzeB]

I know they are different. Obviously the standards does not specify a "right" way to resolve the situation when both __STRICT_ANSI__ and _POSIX_C_SOURCE are used the same time.
I just think letting _POSIX_C_SOURCE win is more useful to users as that seemed to be the only way to disable gnu language extensions (-std=c99 leads to __STRICT_ANSI__ being defined) while still using some posix functions.

[earnie]

If you want both then don't be STRICT. The real issue is C99 compliance is an ISO specification and -ansi is implied when -std=c99 is used.

The macro __STRICT_ANSI__ is predefined when the -ansi option is used. Some header files may notice this macro and refrain from declaring certain functions or defining certain macros that the ISO standard doesn't call for; this is to avoid interfering with any programs that might use these names for other things.

Changes to GCC and other compilers would need to be accepted for the change to occur industry wide for a change to the semantics of how this works. So your best bet is to manage STRICT_ANSI in your files before including the headers with a strong comment as to why you manage it..