This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/2071
- To: pme at gcc dot gnu dot org
- Subject: Re: libstdc++/2071
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: 12 Jun 2001 20:26:03 -0000
- Cc: gcc-prs at gcc dot gnu dot org,
- Reply-To: Benjamin Kosnik <bkoz at redhat dot com>
The following reply was made to PR libstdc++/2071; it has been noted by GNATS.
From: Benjamin Kosnik <bkoz@redhat.com>
To: rittle@labs.mot.com
Cc: mark@codesourcery.com, gcc-gnats@gcc.gnu.org, pedwards@disaster.jaj.com
Subject: Re: libstdc++/2071
Date: Tue, 12 Jun 2001 13:24:28 -0700 (PDT)
> No, you are not an idiot! I can believe that you found another
> (hopefully, minor) independent bug with the library. However, in both
> Solaris and FreeBSD (the two platforms known to have the interactive
> and/or pipe-based cin bug explained in libstdc++/2071), we find:
>
> ; grep SEEK_ /usr/include/stdio.h|grep define
> #define SEEK_SET 0
> #define SEEK_CUR 1
> #define SEEK_END 2
>
> In include/bits/ios_base.h, we fine:
>
> static const seekdir beg = seekdir(0);
> static const seekdir cur = seekdir(SEEK_CUR);
> static const seekdir end = seekdir(SEEK_END);
>
> For maximal portability, I might recommend that we patch the first
> line to read as follows (but in practice, I'm not sure it matters at
> all since I have never seen a libc define SEEK_SET any other way):
Yup. Now that I've had some sleep, I can see that this is an non-issue.
The standard mandates beg as 0, so we are actually correct as is, without
any additional patching.
Thanks for the sanity check.
benjamin