This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should basic_filebuf rely on posix behavior (on Windows)?


Filed a bug as suggested

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64064

>We might consider to use here binary-mode as default for Windows systems.  But your sentence I can follow.

>Yes, but iostreams are supposed to be usable in text mode and perform
>line-ending conversions, like stdio does. Just not using text mode
>dodges the problem but doesn't solve it :-)

Personally I'd be happy with either as long as the behaviour is
consistent, although I can see how removing EOL conversion support
outright might break a lot of existing code.

As it stands seeking a buffered text file using offsets returned by
the library itself is simply broken on Windows when using native EOLs,
and having to work around the issue is less than ideal (although it's
not the biggest of deals).


On 25 November 2014 at 02:15, Jonathan Wakely <jwakely@redhat.com> wrote:
> On 24/11/14 11:22 -0500, Kai Tietz wrote:
>>
>> We might consider to use here binary-mode as default for Windows systems.
>> But your sentence I can follow.
>
>
> I think that would require libstdc++ to do the line-ending conversions
> itself.
>
>> I would suggest to use here instead of just 'std::ios::in' additionally
>> the binary-mode-flag 'std::ios::in | std::ios::binary'.  I tested your
>> sample, and it works nicely.
>
>
> Yes, but iostreams are supposed to be usable in text mode and perform
> line-ending conversions, like stdio does. Just not using text mode
> dodges the problem but doesn't solve it :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]