public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Westley Weimer <weimer@wrw3.resnet.cornell.edu>
To: egcs@cygnus.com
Subject: egcs bug in c++ setw() ?
Date: Tue, 02 Dec 1997 05:52:00 -0000	[thread overview]
Message-ID: <Pine.LNX.3.96.971202083040.1579A-100000@wrw3.resnet.cornell.edu> (raw)

The last two (at least) versions of pgcc / egcs produce executables with
strange setw() behavior. setw() does set the output width, but its
argument overwrites whatever was going to be written next.

Here's an condensed example that demonstrates the problem: 
--- begin testing.cc --- 
#include <iomanip.h>
#include <iostream.h>
#include <stdlib.h>

int main(void)
{
  int i; 
  cout << endl << "The numbers 0 through 9 using setw(3):" << endl;
  for (i = 0 ; i <= 9 ; i++)
    cout << setw(3) << i;
  cout << endl;
  cout << "The numbers 0 through 9 using \"  \" to separate:" << endl;
  for (i = 0 ; i <= 9 ; i++)
    cout << "  " << i;
  cout << endl << endl;
  return(0);
}
--- end testing.cc ---

Here's the output on various systems:

turing% uname -a
SunOS turing.csuglab.cornell.edu 5.5 Generic_103093-03 sun4m sparc
SUNW,SPARCsystem-600
...
Reading specs from
/usr/local/gnu/gcc-2.7.2/lib/gcc-lib/sparc-sun-solaris2.5/2.7.2/specs
gcc version 2.7.2

turing% a.out
The numbers 0 through 9 using setw(3):
  0  1  2  3  4  5  6  7  8  9
The numbers 0 through 9 using "  " to separate:
  0  1  2  3  4  5  6  7  8  9

Everything seems fine. Using egcs on i586/linux: 

merentha:/tmp$ uname -a 
Linux wrw3 2.1.63 #7 Fri Nov 21 16:57:09 EST 1997 i586 unknown
...
Reading specs from
/usr/local/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.90.06/specs
gcc version egcs-2.90.06 970907 (gcc2-970802 experimental)
merentha:/tmp$ a.out
The numbers 0 through 9 using setw(3):
  3  3  3  3  3  3  3  3  3  3
The numbers 0 through 9 using "  " to separate:
  0  1  2  3  4  5  6  7  8  9

That looks bad. Let's try again on the same computer using a more recent
version of pgcc/egcs.  

Reading specs from
/usr/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.90.17p/specs
gcc version egcs-2.90.17p 971114 (gcc2-970802 experimental)
merentha:/tmp$ a.out
The numbers 0 through 9 using setw(3):
  3  3  3  3  3  3  3  3  3  3
The numbers 0 through 9 using "  " to separate:
  0  1  2  3  4  5  6  7  8  9

Note that in both egcs cases 0-9 were replaced by 3. 

Now let's go to an older intel linux that's still using 2.7.2. 

mbs15:~$ uname -a
Linux mbs15 2.0.20 #4 Sat Sep 21 15:18:14 EDT 1996 i486
mbs15:~$ g++ -v
 gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2/specs
gcc version 2.7.2
mbs15:~$ a.out
The numbers 0 through 9 using setw(3):
  0  1  2  3  4  5  6  7  8  9
The numbers 0 through 9 using "  " to separate:
  0  1  2  3  4  5  6  7  8  9

Works like a charm. 

In case this is a library problem, here are the versions I'm using (on the
computer that demonstrates the problem): 
merentha:/tmp$ ll /usr/lib/libg++*
-rw-r--r--   1 root     root      1326034 Aug 20 18:56 /usr/lib/libg++.a
lrwxrwxrwx   1 root     root           16 Sep 20 08:56 /usr/lib/libg++.so -> libg++.so.27.2.8
lrwxrwxrwx   1 root     root           16 Sep 20 08:56 /usr/lib/libg++.so.27 -> libg++.so.27.2.8
-r-xr-xr-x   1 root     root       282527 Feb  3  1997 /usr/lib/libg++.so.27.2.1
-rwxr-xr-x   1 root     root       969891 Aug 20 18:55 /usr/lib/libg++.so.27.2.8
merentha:/tmp$ ll /usr/lib/libstdc++*
-rw-r--r--   1 root     root      1222002 Aug 20 18:56 /usr/lib/libstdc++.a
lrwxrwxrwx   1 root     root           19 Sep 20 08:56 /usr/lib/libstdc++.so -> libstdc++.so.27.2.8
lrwxrwxrwx   1 root     root           19 Sep 20 08:56 /usr/lib/libstdc++.so.27 -> libstdc++.so.27.2.8
-r-xr-xr-x   1 root     root       250948 Feb  3  1997 /usr/lib/libstdc++.so.27.2.1
-rwxr-xr-x   1 root     root       875636 Aug 20 18:55 /usr/lib/libstdc++.so.27.2.8

This problem appears in both dynamic and statically linked versions of the
output file. If I use setw(4), 4 replaces 0-9, etc. It is specifically not
present on machines running gcc 2.7.2. 

If this is a FAQ, or if I'm misinterpreting setw() semantics, my
apologies. 

Is this truly a bug that has crept into egcs since gcc 2.7.2? Or have I
set things up badly? 

Any help would be appreciated, and I'll be happy to provide more
information or run tests to narrow down the problem.

	-Wes Weimer
	wrw3@cornell.edu


             reply	other threads:[~1997-12-02  5:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-12-02  5:52 Westley Weimer [this message]
1997-12-03 16:29 ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.3.96.971202083040.1579A-100000@wrw3.resnet.cornell.edu \
    --to=weimer@wrw3.resnet.cornell.edu \
    --cc=egcs@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).