public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: Documenting stat(2)
Date: 17 Jan 2001 22:46:11 -0800	[thread overview]
Message-ID: <9463fj$gsq$1@penguin.transmeta.com> (raw)
In-Reply-To: <20010118002812.A19810@thyrsus.com>

In article <20010118002812.A19810@thyrsus.com>,
Eric S. Raymond <esr@thyrsus.com> wrote:
>
>* For a socket or FIFO (S_IFSOCK, S_IFIFO) it reports the count of bytes
>waiting to be read. 

Don't depend on it. That's pretty much implementation-defined: use the
FIONREAD ioctl to fetch available info from pipes, sockets, ttys etc.

Some versions of Linux will _not_ give the size of the pipe from stat(),
if I remember correctly.  And as far as I know, no version of Linux will
have st_size mean anything at all for sockets (pipes, yes.  Both named
and unnamed - at least with the current implementation.  But not
sockets.  How could, it, anyway, as a socket name is nothing but a bind
entry, and can have many sockets associated with it?). 

>* For a block special device (S_IFBLK) it returns 0.

Again, this is not something you should depend on. Older Linuxes tried
to return the size of the block device, again if my memory serves me.

>I don't know what it should be expected to return for terminal or
>other special devices.  My guess is number of characters waiting
>in clists.

Nope. Use FIONREAD for that.

Linux will normally return 0.

>Can anyone verify, correct, or expand on the above?  Reply to 
>esr@thyrsus.com, please, and thanks in advance.

Basically, the _only_ think you should depend on is that st_size
contains:
 - for regular files, the size of the file in bytes
 - for symlinks, the length of the symlink.

That's it. Anybody who tries to use anything else is nonportable, and is
almost guaranteed to not work reliably even on just different versions
of Linux, never mind anything else.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2001-01-18  6:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-18  5:28 Documenting stat(2) Eric S. Raymond
2001-01-18  6:46 ` Linus Torvalds [this message]
2001-01-18 12:56 ` Felix von Leitner
  -- strict thread matches above, loose matches on Subject: below --
2001-01-18  7:05 dmeyer
2001-01-18 11:53 ` Padraig Brady
2001-01-18 15:54   ` dmeyer
2001-01-18 20:52   ` Igmar Palsenberg
2001-01-19  1:00     ` Mike Castle
2001-01-20 19:39       ` Igmar Palsenberg
2001-01-19 10:18   ` Andreas Schwab

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='9463fj$gsq$1@penguin.transmeta.com' \
    --to=torvalds@transmeta.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox