On Thu, Jul 28, 2011 at 7:46 PM, Eric Blake wrote:
> On 07/28/2011 07:30 AM, Eric Blake wrote:
> This topic came up again in today's Austin Group meeting, reaffirming that
> Solaris behavior is correct and glibc 2.14 behavior, while fixing one aspect
> of fclose, caused an an unintentional regress
On 07/28/2011 07:30 AM, Eric Blake wrote:
f = fdopen (fd2, "w");
assert (f);
+ printf("%ld\n", ftell(f));
So far, so good. fdopen() is required to set the stream position to the
same as the underlying fd position, so this should always print 1.
assert(lseek(fd, 4, SEEK_SET) == 4);
+ printf("%
On 07/28/2011 02:00 AM, Csaba Henk wrote:
- However, it seems to me that the cited part of the standard
is not sufficient to make a judgement regarding which
of glibc 2.14 and Solaris is the standard compliant.
There is a more fundamental semantic difference here.
Let us modify the
On Wed, Jul 27, 2011 at 02:58:08PM -0600, Eric Blake wrote:
> > On 07/27/2011 09:31 AM, Csaba Henk wrote:
[...]
> | At page 805 line 26801 section fclose, change:
> |
> | the file offset of the underlying open file description shall be
> | adjusted so that the next operation on the open f
[adding bug-gnulib]
On 07/27/2011 09:31 AM, Csaba Henk wrote:
Hi,
Bugzilla entry #12724 proposes a (by now committed) change
to fclose(3) behavior based on the following citation from
POSIX.1-2008:
"If the file is not already at EOF, and the file is one capable
of seeking, the file offset of t