This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Why fixing 9533 doesn't fix 7744: revealed!
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 at cantrip dot org