Strange characters from cout
Hello, I compiled a c++ rpm install program which gives some strange/unexpected output while using cout. I have consulted several sources, but untill now no success. The output I get is the following: After unpacking 11.2MB of additional disk space will be used. \?x×Bèÿ¿ÀT?@àçÿ¿ØÿX@èçÿ¿mBM@ \?x×Bèÿ¿ÀT?@àçÿ¿ØÿX@èçÿ¿mBM@ Executing RPM (-Uvh)... Preparing... ########################################### [100%] 1:python-devel ########################################### [100%] or Do you want to continue? [Y/n] \?x×Bèÿ¿ÀT?@àçÿ¿ØÿX@èçÿ¿mBM@ \?x×Bèÿ¿ÀT?@àçÿ¿ØÿX@èçÿ¿mBM@ \?x×Bèÿ¿ÀT?@àçÿ¿ØÿX@èçÿ¿mBM@ \?x×Bèÿ¿ÀT?@àçÿ¿ØÿX@èçÿ¿mBM@ \?x×Bèÿ¿ÀT?@àçÿ¿ØÿX@èçÿ¿mBM@ \?x×Bèÿ¿ÀT?@àçÿ¿ØÿX@èçÿ¿mBM@ \?x×Bèÿ¿ÀT?@àçÿ¿ØÿX@èçÿ¿mBM@ Executing RPM (-Uvh)... ?èÿ¿Za0 The involved code looks as follows: { ...... const char *operation; .... case Item::RPMUpgrade: if (Interactive) operation = "-Uvh"; else operation = "-Uv"; break; .... cout << _("Executing RPM (")<<operation<<")..." << endl; For the record: The exact same source has been used on suse-8.2 as well, and it did not show the problem. The compilation and execution has been performed with different LANG= settings. They do not seem to matter. The problem persist if cout is altered for cerr. If a "\n" is added to the variable operation as follows: case Item::RPMUpgrade: if (Interactive) operation = "-Uvh\n"; else operation = "-Uv"; break; ...... cout << "Executing RPM (" << operation << ")..." << endl; The output is now: Executing RPM (-Uvh@,¤E@è´B@0@8ȸçÿ¿0@ )... Or if the variable is assigned an empty string the following result is obtained: After unpacking 11.5kB of additional disk space will be used. RPM version 4.1.1/F@,¤E@è´B@0@8ȸçÿ¿0@ <<<<<<=========== Copyright (C) 1998-2002 - Red Hat, Inc. This program may be freely redistributed under the terms of the GNU GPL Does anyone know what the cause of this behaviour can be? Incorrect programming? Is the definition of the variable incorrect, something else?? -- TIA, Richard Bos Without a home the journey is endless
Richard Bos wrote:
{ ...... const char *operation; .... case Item::RPMUpgrade: if (Interactive) operation = "-Uvh"; else operation = "-Uv"; break; .... cout << _("Executing RPM (")<<operation<<")..." << endl;
Have you tried putting a null character at the end of the strings: i.e. operation = "-Uvh\0" This is a C-style string - I try to avoid them because std::string is better - and should be null terminated. I think the compiler should null terminate the strings for you, but if it doesn't it should just spew out what it finds as characters until it finds a null character or segfaults. That may be what you're seeing. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
On Tue, Nov 04, 2003 at 09:30:54PM +0000, John Lamb wrote:
Richard Bos wrote:
{ ...... const char *operation; .... case Item::RPMUpgrade: if (Interactive) operation = "-Uvh"; else operation = "-Uv"; break; .... cout << _("Executing RPM (")<<operation<<")..." << endl;
Have you tried putting a null character at the end of the strings: i.e.
operation = "-Uvh\0"
This is a C-style string - I try to avoid them because std::string is better - and should be null terminated.
Actually, "-Uvh" is already null terminated and you shouldn't use the \0 explicitly. The parenthesis around the cout are somewhat weird, and I dunno what is that _. Better: cout << "Executing RPM (" << operatiion << ")..." << endl; Are you sure that the case Item::RPMUpgrade is really reached? Try initializing operation with something, like const char *operator = "invalidop"; []s Davi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 04 Nov 2003 21:30:54 +0000 John Lamb <J.D.Lamb@btinternet.com> wrote:
Richard Bos wrote:
{ ...... const char *operation; .... case Item::RPMUpgrade: if (Interactive) operation = "-Uvh"; else operation = "-Uv"; break; .... cout << _("Executing RPM (")<<operation<<")..." << endl;
Have you tried putting a null character at the end of the strings: i.e.
operation = "-Uvh\0"
This is a C-style string - I try to avoid them because std::string is better - and should be null terminated. I think the compiler should null terminate the strings for you, but if it doesn't it should just spew out what it finds as characters until it finds a null character or segfaults. That may be what you're seeing.
The literal string (e.g. "xxxxxx") is always nul terminated in C or C++. And, std::string uses the c-string internally. In any case, from the looks of the garbage, I'm wondering if Richard might have a problem with the locale. I don't suspect that the problem is with the iostream package per se. - -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/rPm6+wA+1cUGHqkRAnkqAJ0VhN0zUVTKynKYlPJomf3zZY3WFgCfYkjC hQb/b1Ul9roETBVJ8jK9AYE= =kaNO -----END PGP SIGNATURE-----
Jerry and others, thank you for your thoughts and idea's sofar, but I still did not find the cause. I would like to try the following: - At 8.2 if possible install the suse-9.0 gcc-c++ compiler. This is version 3.3.1 while 8.2 comes with 3.3. That way I can detect if the problem is introduced by the compiler change. Oh the other way is possible too of course, install gcc-c++-3.3 in suse-9.0. Does anyone see problem with down/up grading the compiler? Op zaterdag 8 november 2003 15:12, schreef Jerry Feldman:
This is a C-style string - I try to avoid them because std::string is better - and should be null terminated. I think the compiler should null terminate the strings for you, but if it doesn't it should just spew out what it finds as characters until it finds a null character or segfaults. That may be what you're seeing.
The literal string (e.g. "xxxxxx") is always nul terminated in C or C++. And, std::string uses the c-string internally.
In any case, from the looks of the garbage, I'm wondering if Richard might have a problem with the locale. I don't suspect that the problem is with the iostream package per se.
-- Richard Bos Without a home the journey is endless
Richard Bos wrote:
Jerry and others,
thank you for your thoughts and idea's sofar, but I still did not find the cause. I would like to try the following:
- At 8.2 if possible install the suse-9.0 gcc-c++ compiler. This is version 3.3.1 while 8.2 comes with 3.3. That way I can detect if the problem is introduced by the compiler change. Oh the other way is possible too of course, install gcc-c++-3.3 in suse-9.0.
Does anyone see problem with down/up grading the compiler?
Upgrading SuSE 8.2 compiler to gcc3.3.1 should be easy because the RPMs are already available on ftp://ftp.suse.com/pub/projects/gcc/8.2/ -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Op zaterdag 8 november 2003 19:03, schreef John Lamb:
Does anyone see problem with down/up grading the compiler?
Upgrading SuSE 8.2 compiler to gcc3.3.1 should be easy because the RPMs are already available on ftp://ftp.suse.com/pub/projects/gcc/8.2/
Ah another possibility. I though of using the suse-9.0 gcc-3.3.1 rpms on suse-8.2 or the other way around the suse-8.2 3.3 rpm on suse-9.0 May that any side effects? -- Richard Bos Without a home the journey is endless
Richard Bos wrote:
Ah another possibility. I though of using the suse-9.0 gcc-3.3.1 rpms on suse-8.2 or the other way around the suse-8.2 3.3 rpm on suse-9.0 May that any side effects?
Possibly. The two versions depend on different libraries and so you would have to update those also on SuSE 8.2. I don't know if the 3.3 RPMs would work on 9.0, but rpm will surely complain about replacing a newer package. I installed the RPMS on 8.2 from http://www.mirror.ac.uk/sites/ftp.suse.com/pub/projects/gcc/8.2/ which is closer to you than it is to me and is a lot faster than ftp.suse.com. These RPMs came out just before SuSE 9.0 was released. I have had no problems with them. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Op zaterdag 8 november 2003 19:53, schreef John Lamb:
Richard Bos wrote:
Ah another possibility. I though of using the suse-9.0 gcc-3.3.1 rpms on suse-8.2 or the other way around the suse-8.2 3.3 rpm on suse-9.0 May that any side effects?
Possibly. The two versions depend on different libraries and so you would have to update those also on SuSE 8.2. I don't know if the 3.3 RPMs would work on 9.0, but rpm will surely complain about replacing a newer package.
While trying to install the 8.2 gcc-c++ version on 9.0 I run into the underneath unexpected (to me) dependency: pilchard:/usr/tmp # rpm -Uvh /usr/tmp/gcc-c++-3.3-23.i586.rpm gcc-3.3-23.i586.rpm error: Failed dependencies: cpp = 3.3-23 is needed by gcc-3.3-23 pilchard:/usr/tmp # rpm -e cpp error: Failed dependencies: /lib/cpp is needed by (installed) XFree86-4.3.0.1-29 Does XFree86 really depends on cpp? richard@pilchard:/usr/tmp> rpm -q.... cpp Group : Development/Languages/C and C++Summary : The GCC Preprocessor Description : This Package contains just the preprocessor that is used by the XFree86 I understand that XFree86-devel depends on cpp, but XFree itself no. Is this a dependency bug? Will it indeed be safe to remove cpp, without crashing X? -- Richard Bos Without a home the journey is endless
Richard Bos <radoeka@xs4all.nl> [Sat, 8 Nov 2003 22:21:11 +0100]:
I understand that XFree86-devel depends on cpp, but XFree itself no. Is this a dependency bug?
AFAIR, cpp is used for resource handling. But it's only preprocessing of non C code, so almost any cpp should do. Philipp
Op zondag 9 november 2003 03:01, schreef Philipp Thomas:
Richard Bos <radoeka@xs4all.nl> [Sat, 8 Nov 2003 22:21:11 +0100]:
I understand that XFree86-devel depends on cpp, but XFree itself no. Is this a dependency bug?
AFAIR, cpp is used for resource handling. But it's only preprocessing of non C code, so almost any cpp should do.
Philipp
Philipp, thanks for your feedback. The spec file explicitely list the dependency to lib/cpp: Name: XFree86 Requires: xf86tools /lib/cpp In the changelog the following update has been made: * Thu Mar 22 2001 - sndirsch@suse.de - added '/lib/cpp' to Requires: of xf86 (needed by xrdb) May I question this dependency, why should xrdb need cpp? As the man page says The C preprocessor is intended to be used only with C, C++, and Objective-C source code. Of course the dependency is not just added like that, it would therefor be interesting to know why xrdb needs it. Anyhow, perhaps the dependency should be reconsidered and be removed? -- Richard Bos Without a home the journey is endless
Richard Bos <radoeka@xs4all.nl> [Sun, 9 Nov 2003 22:45:21 +0100]:
- added '/lib/cpp' to Requires: of xf86 (needed by xrdb)
May I question this dependency, why should xrdb need cpp? As the man page says The C preprocessor is intended to be used only with C, C++, and Objective-C source code.
Remember that X11 is quite old in computer terms. cpp is not only used for X resources by xrdb but also the complete source configuration is done via (mis)use of the preprocessor. If you have the X11 devel stuff installed, just look at the stuff in /usr/X11R6/lib/X11/config and you'll see what I mean. This (mis)use of cpp has caused the gcc developers quite a few headaches as it relies on the behavior of the traditional C preprocessor which is useless and unwanted in a preprocessor for modern C.
Of course the dependency is not just added like that, it would therefor be interesting to know why xrdb needs it. Anyhow, perhaps the dependency should be reconsidered and be removed?
No, xrdb really needs the C preprocessor, so there's no way around that dependency. Philipp
Op zondag 9 november 2003 23:09, schreef Philipp Thomas:
Of course the dependency is not just added like that, it would therefor be interesting to know why xrdb needs it. Anyhow, perhaps the dependency should be reconsidered and be removed?
No, xrdb really needs the C preprocessor, so there's no way around that dependency.
Okay, no problem with it than. -- Richard Bos Without a home the journey is endless
Op zaterdag 8 november 2003 17:03, schreef Richard Bos:
Jerry and others,
thank you for your thoughts and idea's sofar, but I still did not find the cause. I would like to try the following:
- At 8.2 if possible install the suse-9.0 gcc-c++ compiler. This is version 3.3.1 while 8.2 comes with 3.3. That way I can detect if the problem is introduced by the compiler change. Oh the other way is possible too of course, install gcc-c++-3.3 in suse-9.0.
Does anyone see problem with down/up grading the compiler?
The compiler downgrade worked okay and I'm very very pleased to have found the cause of the strange characters in the output of my compiled executable! The exact same sources built on exact the same system (9.0) do not give the strange and unexpected characters with gcc-c++ 3.3 (suse-8.2)! Now what to do? Can anyone of suse jump in to help to find the bug in gcc or must I redirect my bug to the gcc mailinglist? -- Richard Bos Without a home the journey is endless
Richard Bos wrote:
Now what to do? Can anyone of suse jump in to help to find the bug in gcc or must I redirect my bug to the gcc mailinglist?
If you're sure it's a compiler bug, try http://gcc.gnu.org/bugzilla/. There are a few other possibilities so it's best to thin the code down until it does nothing other than repeat the bug. -- JDL Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
participants (5)
-
davicastro＠terra.com.br -
Jerry Feldman -
John Lamb -
Philipp Thomas -
Richard Bos