Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: fflush stdin in actsync (Julien ?LIE)
2. Re: fflush stdin in actsync (Bo Lindbergh)
3. Re: fflush stdin in actsync (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Sun, 3 Apr 2016 15:47:16 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: fflush stdin in actsync
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Richard,
>> In backends/actsync.c, we use "fflush(stdin)" that has undefined
>> behaviour (portability issue).
>> Has someone ever encountered an issue with actsync because of that?
>>
>> Is it worth trying to fix it? (using scanf for instance and discarding
>> output)
>
> It's undefined in C99 but has defined behavior in SUS:
>
> For a stream open for reading, if the file is not already at EOF, and
> the file is one capable of seeking, the file offset of the underlying
> open file description shall be set to the file position of the stream,
> and any characters pushed back onto the stream by ungetc() or ungetwc()
> that have not subsequently been read from the stream shall be discarded
> (without further changing the file offset)
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fflush.html
>
> So it depends what the portability goal is.
Thanks for your answer.
I was having a look at the result of cppcheck against INN source code.
One of the errors found is in backends/actsync.c:
(error) fflush() called on input stream 'stdin' results in
undefined behaviour.
That's why I wonder whether it would be worth fixing.
As POSIX 2013 now defines it (according to the page you quoted), maybe
we could keep it as-is.
--
Julien ?LIE
? The hardest thing is to go to sleep at night, when there are so many
urgent things needing to be done. A huge gap exists between what we
know is possible with today's machines and what we have so far been
able to finish. ? (Donald Knuth)
------------------------------
Message: 2
Date: Sun, 3 Apr 2016 17:03:40 +0200
From: Bo Lindbergh <[email protected]>
To: [email protected]
Subject: Re: fflush stdin in actsync
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Quoth Richard Kettlewell:
> It's undefined in C99 but has defined behavior in SUS:
>
> For a stream open for reading, if the file is not already at EOF, and
> the file is one capable of seeking, the file offset of the underlying
> open file description shall be set to the file position of the stream,
> and any characters pushed back onto the stream by ungetc() or ungetwc()
> that have not subsequently been read from the stream shall be discarded
> (without further changing the file offset)
That sounds like the intended use is for syncing the position
of a file descriptor that is going to be inherited by another program.
However, this is not what the exec_cmd function in actsync.c does;
it calls fclose(stdin) in the child process before exec-ing ctlinnd.
I suggest deleting the fflush(stdin).
/Bo Lindbergh
------------------------------
Message: 3
Date: Sun, 03 Apr 2016 11:03:12 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: fflush stdin in actsync
Message-ID: <[email protected]>
Content-Type: text/plain
Bo Lindbergh <[email protected]> writes:
> However, this is not what the exec_cmd function in actsync.c does;
> it calls fclose(stdin) in the child process before exec-ing ctlinnd.
> I suggest deleting the fflush(stdin).
+1. Even though it arguably has defined behavior, I'm quite dubious that
actsync is actually relying on that behavior.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 83, Issue 3
******************************************
