bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 15/21] freopen: workaround freopen() on OS/2 kLIBC


From: Bruno Haible
Subject: Re: [PATCH 15/21] freopen: workaround freopen() on OS/2 kLIBC
Date: Thu, 04 Dec 2014 11:55:23 +0100
User-agent: KMail/4.8.5 (Linux/3.2.0-64-generic; KDE/4.8.5; x86_64; ; )

KO Myung-Hun wrote:
> --- a/lib/freopen.c
> +++ b/lib/freopen.c
> @@ -26,10 +26,26 @@
>  #include <stdio.h>
>  #undef __need_FILE
>  
> +#include <errno.h>
> +
>  static FILE *
>  orig_freopen (const char *filename, const char *mode, FILE *stream)
>  {
> -  return freopen (filename, mode, stream);
> +  FILE *result;
> +
> +  /* Clear errno to check the success of freopen() with it */
> +  errno = 0;
> +
> +  result = freopen (filename, mode, stream);
> +
> +#ifdef __KLIBC__
> +  /* On OS/2 kLIBC, freopen() returns NULL even if it is successful
> +     if filename is NULL. */
> +  if (!filename && !result && !errno)
> +    result = stream;
> +#endif
> +
> +  return result;
>  }
>  
>  /* Specification.  */

Just a question of coding style: We have a chain of invocations
  rpl_freopen -> orig_freopen -> freopen
While, in theory, you can put workarounds in either rpl_freopen or orig_freopen,
the function name 'orig_freopen' and the comment
  /* Get the original definition of freopen.
indicate that 'orig_freopen' should remain a simple invocation of freopen,
and the workaround should go into rpl_freopen. This is the canonical way we've
been using in gnulib (see fopen.c, fstat.c, lstat.c, open.c, openat.c etc.).
I see no reason to abandon this convention.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]