Why fixing 9533 doesn't fix 7744: revealed!

[Nathan Myers]

On Thu, Mar 06, 2003 at 12:19:33AM +0100, Paolo Carlini wrote:
> Seriously, fstat64 I can probably spare, for now, I think... currently
> we don't support large files at all, right?

"Support" is a big word.  If the user has a file descriptor they got via 
open64, they can read from it, but can't seek very far.  Still, for a 
first approximation you might just report 0 from showmanyc if recv and 
fstat both fail, and forget abouit fstat64 for now.  (But put in a FIXME 
comment.)

> (there is a long standing PR about this, 8610, which definitely I would
> rather address in a couple of months, not now ;)
> 
> As regards the other options, could you please help me a bit?
> 
> - S_ISREG vs S_IFREG: the first one is Posix, the latter not, I think.
>  Probably AC_TRY_COMPILE tests are needed for the first with a fallback
>  option for the second, right?

Sounds good.

> - MSG_* flags: I admit my ignorance: I tried what you suggested on Linux
>  and everything worked flawlessly. Where can I find a description of the
>  other possibilities?

Just try to compile with that ::recv() line with all its arguments, and 
if it compiles, then showmanyc can use it; otherwise, it should just 
skip it.  I.e., don't try to make separate flags for ::recv, MSG_this 
and MSG_that, just make one flag, something like RECV_PEEK_SAFE.

The flag value MSG_NOSIGNAL isn't mentioned in Stevens, so might not
exist everywhere.  Maybe we shouldn't use MSG_NOSIGNAL -- if the client 
doesn't want SIGPIPE, he can sigignore it himself.

We might have to experiment with recv.  The docs aren't too clear
on what it reports if the buffer pointer and size are zero.

Nathan Myers
ncm-nospam@cantrip.org