All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Moss <moss@brutesquad.org>
To: linux-kernel@vger.kernel.org
Subject: fstat issues
Date: Sat, 8 Dec 2001 13:17:04 -0500	[thread overview]
Message-ID: <20011208181704.GA25104@acmeunix.org> (raw)

I noticed recently that the following no longer works.  I was wondering if
this is internal to the kernel or if perhaps this is a glibc issue.  Also
wondering if this was an intential change.  It did 'used to work' but I
realize that may hold little to no ground since it does seem to be on a per
implementation basis.  Anyway looking forward to hearing back, feel free to
show a better way to go about doing what I'm attempting to do.
     -James Moss

-------foo.c------------
#include <stdio.h>
#include <sys/types.h>
#include <sys/file.h>
#include <sys/stat.h>
#include <sys/errno.h>
#include <fcntl.h>

main(argc, argv)
int argc;
char **argv;
{
    struct stat sb;
    if (0 == fstat( fileno(stdin), &sb )) {
        printf( "size %d\n", sb.st_size );
    } else {
        printf( "size %d\n", sb.st_size );
    }
    exit( 0 );
}

-------------------
				    
On HP, Solaris, etc...
cc foo.c
echo "abc" > ftext.txt
./a.out < ftext.txt
size 4
cat ftext.txt | ./a.out
size 4
			    
On Debian Unstable, latest release of Suse, and latest release of Redhat...
gcc foo.c
echo "abc" > ftext.txt
./a.out < ftext.txt
size 4
cat ftext.txt | ./a.out
size 0

Page 90, 4.12 "File Size"
Advanced Programming in the UNIX Environment states that it's posix compliant
in SVR4 to have the ability to read file size from a pipe and the st_size of
the sb struct is defined.... does Linux break SVR4 compliance?  Is there a
better or new way to do this?

SVID Vol: 1a Version 4

Since a pipe is bi-directional, there are two separate flows of data.
Therefore, the size (st_size) returned by a call to fstat with argument
fildes[0] or fildes[1] is the number of bytes available for reading from
fildes[0] or fildes[1] respectively.

FINAL COPY
June 15, 1995
File: ba_os/pipe
svid
Page: 219

                 reply	other threads:[~2001-12-08 18:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011208181704.GA25104@acmeunix.org \
    --to=moss@brutesquad.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.