home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!stanford.edu!lucid.com!lucid.com!jss
- From: jss@lucid.com (Jerry Schwarz)
- Subject: Re: Bizarre Borland stream bug
- Message-ID: <1992Jul30.234906.17943@lucid.com>
- Sender: usenet@lucid.com
- Reply-To: jss@lucid.com (Jerry Schwarz)
- Organization: Lucid, Inc.
- References: <1992Jul30.185327.662@news2.cis.umn.edu> <1992Jul30.193832.2535@noose.ecn.purdue.edu>
- Date: Thu, 30 Jul 92 23:49:06 GMT
- Lines: 33
-
- In article <1992Jul30.193832.2535@noose.ecn.purdue.edu>, psmith@iies.ecn.purdue.edu (Paul Smith) writes:
- ||>
- |> Looks kinda like it is reading 0009 as an octal constant because of
- |> the leading zeros, except that 9 isn't a valid octal digit so it gets
- |> bumped to the next read.
- |>
- |> Is this correct behavior? I dunno.
- |>
-
-
- This is correct behavior if the ios::basefield of a stream
- has no bits set by default. For input that condition means
- use C lexical conventions.
-
- So the answer to the original problem is to set that field
- explicitly.
-
- in.setf(ios::dec,ios::basefield) ;
-
-
- The tricky part of the question is whether Borland is
- properly initializing flags hen an istream is constructed.
- The original AT&T documentation (which I wrote) doesn't say.
- Although the code (which I also wrote) initialized to
- ios::skipws|ios::dec. Not documenting that was a
- bad oversight. The latest working paper from X3J16 (which I
- have also had a hand in) says initialize to zero, but I've
- just made a note to review that decision.
-
- -- Jerry Schwarz
-
-
-
-