"Claus Hentschel" <[EMAIL PROTECTED]> writes:
| > | > ios::text? No. It is a non-standard flag.
| > | > ...
| > | > ios::binary otoh is a standard flag and should work everywhere.
| > |
| > | So there seems not to be another way then removong those trailing \r's
| the
| > | way I'v done. We do nee
> | > ios::text? No. It is a non-standard flag.
> | > ...
> | > ios::binary otoh is a standard flag and should work everywhere.
> |
> | So there seems not to be another way then removong those trailing \r's
the
> | way I'v done. We do need that in all cases where text read from a
(binary)
> | opene
"Claus Hentschel" <[EMAIL PROTECTED]> writes:
| > | > Of course it could be done easier with
| > | > ifstream ifs(tmp.c_str(), ios::in | ios::text);
| > | > Maybe we should include that instead ;-) And we can rewrite all calls
| to
| > | > open a file for both reading and writing.
| > |
| > |
> | > Of course it could be done easier with
> | > ifstream ifs(tmp.c_str(), ios::in | ios::text);
> | > Maybe we should include that instead ;-) And we can rewrite all calls
to
> | > open a file for both reading and writing.
> |
> | Does that work?
No, not with gcc, because gcc is conform wit
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Jan 08, 2003 at 09:55:18AM +0100, Claus Hentschel wrote:
| > Lyx should run independent from the mode a drive is mounted. Therefore we
| > need binary mode in some cases and text mode in some other cases whereas in
| > most cases it doesn't matte
On Wed, Jan 08, 2003 at 09:55:18AM +0100, Claus Hentschel wrote:
> Lyx should run independent from the mode a drive is mounted. Therefore we
> need binary mode in some cases and text mode in some other cases whereas in
> most cases it doesn't matter.
>
> Of course it could be done easier with
>
> > Not with Win32! Have a look into src/support/os_win32.C. There
> > os::read:mode() does return "rb" for Win32!
>
> I think this has nothing to do with the \r in LaTeX.C. There an ordinary
> ifstream is used without giving the std::ios_base::binary flag, so this
> should read in text mode.
>
> W
On Tue, Jan 07, 2003 at 06:13:36PM +0100, Claus Hentschel wrote:
> > > That's the reason! In Lyx we do open *all* files the same way, i.e. in
> > > binary mode by default.
> >
> > No, the default mode is text.
>
> Not with Win32! Have a look into src/support/os_win32.C. There
> os::read:mode() doe
> > That's the reason! In Lyx we do open *all* files the same way, i.e. in
> > binary mode by default.
>
> No, the default mode is text.
Not with Win32! Have a look into src/support/os_win32.C. There
os::read:mode() does return "rb" for Win32!
> > To distinguish between text/binary mode we should
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Jan 07, 2003 at 05:42:53PM +0100, Lars Gullik Bjønnes wrote:
>> | That's the reason! In Lyx we do open *all* files the same way, i.e. in
>> | binary mode by default.
>>
>> On a win box text mode is default...
>
| To be precise: text mode is ever
On Tue, Jan 07, 2003 at 05:42:53PM +0100, Lars Gullik Bjønnes wrote:
> | That's the reason! In Lyx we do open *all* files the same way, i.e. in
> | binary mode by default.
>
> On a win box text mode is default...
To be precise: text mode is everywhere default. But there is no difference
between t
"Claus Hentschel" <[EMAIL PROTECTED]> writes:
| > Lars> Andre Poenitz <[EMAIL PROTECTED]> writes:
| > Lars> | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
| > Lars> | > I just got confirmation from de.comp.lang.iso-c++ that | >
| > Lars> getline() should never return the '\r' if
On Tue, Jan 07, 2003 at 05:27:33PM +0100, Claus Hentschel wrote:
> > Lars> Andre Poenitz <[EMAIL PROTECTED]> writes:
> > Lars> | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
> > Lars> | > I just got confirmation from de.comp.lang.iso-c++ that | >
> > Lars> getline() should never
> Lars> Andre Poenitz <[EMAIL PROTECTED]> writes:
> Lars> | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
> Lars> | > I just got confirmation from de.comp.lang.iso-c++ that | >
> Lars> getline() should never return the '\r' if the stream is in | >
> Lars> text mode.
That's the re
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Andre Poenitz <[EMAIL PROTECTED]> writes:
Lars> | On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
Lars> | > I just got confirmation from de.comp.lang.iso-c++ that | >
Lars> getline() should never return the '\r'
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
| > I just got confirmation from de.comp.lang.iso-c++ that
| > getline() should never return the '\r' if the stream is in
| > text mode.
|
| Next asnwer says: This is a well-known bug
On Tue, Jan 07, 2003 at 12:31:00PM +0100, Andre' Poenitz wrote:
> I just got confirmation from de.comp.lang.iso-c++ that
> getline() should never return the '\r' if the stream is in
> text mode.
Next asnwer says: This is a well-known bug in some Borland Compiler
("BCB5"). Upgrading or using
On Tue, Jan 07, 2003 at 12:43:14PM +0100, Jean-Marc Lasgouttes wrote:
> Andre> It shouldn't for the common case of putting the line into
> Andre> istringstream and reading from there.
>
> Why? What is the magic making this happen?
"The streambuffer layer". I have asked what this means ;-)
Andre'
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Tue, Jan 07, 2003 at 10:37:19AM +0100, Lars Gullik Bjønnes
Andre> wrote:
>> all calls to getline is followed by a call to rtrim...
Andre> Indeed.
Andre> I now just wonder why the removal of the '\r' is necessary at
Andre> all.
I just got confirmation from de.comp.lang.iso-c++ that
getline() should never return the '\r' if the stream is in
text mode.
So which compiler was that?
The only possibility is a '\r\r\n' in the raw input...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Andre Poenitz <[EMAIL PROTECTED]> writes:
Lars> | On Mon, Jan 06, 2003 at 09:41:01PM +0100, Lars Gullik Bjønnes wrote:
Lars> | > | A single char obviously can't be '\r\n'. So I'd indeed
Lars> expect a '\r' at the | > | end of th
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Jan 07, 2003 at 10:37:19AM +0100, Lars Gullik Bjønnes wrote:
| > all calls to getline is followed by a call to rtrim...
|
| Indeed.
|
| I now just wonder why the removal of the '\r' is necessary at all.
|
| It shouldn't for the common case of
Andre Poenitz <[EMAIL PROTECTED]> writes:
| I wonder what happens if we used
|
| getline(s,n,widen('\n'))
This is just what getline(s, n) ends up in.
--
Lgb
On Tue, Jan 07, 2003 at 10:44:52AM +0100, Jean-Marc Lasgouttes wrote:
> Andre> The problem is, not to many people here have a Windows
> Andre> development system to check. The ifstream in question is not
> Andre> opened in binary mode as far as I can tell, so optically it
> Andre> should work. Neve
On Tue, Jan 07, 2003 at 10:37:19AM +0100, Lars Gullik Bjønnes wrote:
> all calls to getline is followed by a call to rtrim...
Indeed.
I now just wonder why the removal of the '\r' is necessary at all.
It shouldn't for the common case of putting the line into istringstream and
reading from there.
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> The problem is, not to many people here have a Windows
Andre> development system to check. The ifstream in question is not
Andre> opened in binary mode as far as I can tell, so optically it
Andre> should work. Nevertheless, the '\r'
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jan 06, 2003 at 09:41:01PM +0100, Lars Gullik Bjønnes wrote:
| > | A single char obviously can't be '\r\n'. So I'd indeed expect a '\r' at the
| > | end of the string read by getline(...'\n') -- unless this has something
| > | to do with that 'bi
On Mon, Jan 06, 2003 at 09:41:01PM +0100, Lars Gullik Bjønnes wrote:
> | A single char obviously can't be '\r\n'. So I'd indeed expect a '\r' at the
> | end of the string read by getline(...'\n') -- unless this has something
> | to do with that 'binary mode' vs 'text mode' and the \r is removed ear
Andre Poenitz <[EMAIL PROTECTED]> writes:
| A single char obviously can't be '\r\n'. So I'd indeed expect a '\r' at the
| end of the string read by getline(...'\n') -- unless this has something
| to do with that 'binary mode' vs 'text mode' and the \r is removed earlier.
| Somehow...
This is exac
On Mon, Jan 06, 2003 at 06:43:28PM +0100, Lars Gullik Bjønnes wrote:
> I am not sure why this patch is needed. I thought that a standard
> conforming ifstream + getline would remove the line ending on the
> system it runs. Thus in the case of win32 it should remove \r\n.
Hm.
template
basic_
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> The following patch is adapted from one of the last bits in the
Lars> patch | that Claus Hentschel uses on win32. It fixes parsing of
Lars> log files by | removing trailin
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| The following patch is adapted from one of the last bits in the patch
| that Claus Hentschel uses on win32. It fixes parsing of log files by
| removing trailing \r.
|
| OK to apply?
Not sure...
I am not sure why this patch is needed. I thought
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> The following patch is adapted from one of the last bits in
Jean-Marc> the patch that Claus Hentschel uses on win32. It fixes
Jean-Marc> parsing of log files by removing trailing \r.
Jean-Marc> OK to apply?
Lars, ca
The following patch is adapted from one of the last bits in the patch
that Claus Hentschel uses on win32. It fixes parsing of log files by
removing trailing \r.
OK to apply?
JMarc
? config.h.in
? src/ext_l10n.h
Index: src/ChangeLog
=
34 matches
Mail list logo
