Re: fprintf() crashes on wide-oriented stream.

[Corinna Vinschen <vinschen@redhat.com>]

On Nov  7 09:50, Brian Inglis wrote:
> On 2023-11-07 06:24, Corinna Vinschen wrote:
> > It took me a while, but I think the BSD behaviour is only accepted
> > (acceptable) due its long history.  The only really correct way of
> > handling this issue is to do soemthing along the lines of GLibC.
> > 
> > I. e., while "cannot be applied" is sufficently vague, it should be
> > interpreted as "must not be applied", basically.  However, "must not"
> > kind of implies setting errno, but there's not a trace of that in
> > the standard.
> > 
> > Consequentially, IMHO, the way GLibC handles it sounds like the best way
> > out: The call is a no-op and returns a value indicating that the stream
> > isn't available for the given operation (EOF/WEOF/younameit), but it
> > does not change errno.  There's no errno value defined for this kind
> > of problem anyway.
> 
> POSIX disagrees with glibc and states that errno should be set (to EALREADY,
> EBADF, EBADFD, EIO, ENOTSUP, EPERM, or add EORIENT or EWIDTH?) and callers
> need to do "the errno shuffle":
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fwide.html
> 
> "[CX] [Option Start] The fwide() function shall not change the setting of
> errno if successful.
> 
> Since no return value is reserved to indicate an error, an application
> wishing to check for error situations should set errno to 0, then call
> fwide(), then check errno, and if it is non-zero, assume an error has
> occurred. [Option End]"

You're totally missing the point.  The POSIX text is about an error
occuring in fwide(3), and the only possible error in fwide(3) is an
invalid file pointer.  Given that fwide(3) doesn't define a return
value indicating an error, the above errno checking is required in
the application.

However, Takashi's input and code as well as my reply are talking about
all the other stdio functions depending on the orientation value.  The
stdio function behaviour in terms of orientation has nothing to do with
the POSIX description of fwide(3) you're quoting.


Corinna