ofstream problem

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1

I have a QNX4 program that I’m porting to QNX6 that exhibits a problem
with ofstream. The program was quite large but I was able to trim it
down to the following:

============================
#include <fstream.h>

ofstream outfile; // this would get opened subsequently

int main ( )
{ return 0; }

This compiles OK but if I try to run it it crashes with a SIGSEGV.

If I change the #include to include (no ‘.h’), it won’t even
compile. Not sure why?

I tried linking against both gpp and cpp libs.

2

Bill Caroselli <qtps@earthlink.net> wrote:
BC > I have a QNX4 program that I’m porting to QNX6 that exhibits a problem
BC > with ofstream. The program was quite large but I was able to trim it
BC > down to the following:

BC > ============================
BC > #include <fstream.h>

BC > ofstream outfile; // this would get opened subsequently

BC > int main ( )
BC > { return 0; }
BC > ============================

BC > This compiles OK but if I try to run it it crashes with a SIGSEGV.

BC > If I change the #include to include (no ‘.h’), it won’t even
BC > compile. Not sure why?

BC > I tried linking against both gpp and cpp libs.

New information:

This fails if compiled & linked with gcc_ntox86 or gcc_ntox86_cpp. But
it does work as expected using gc_ntox86_gpp. I would like to use Dinkum
(_cpp). What must I do to make that version work?

BTW, what is the difference between gcc_ntox86 and gcc_ntox86_gpp?

3

Bill Caroselli wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote:
BC > I have a QNX4 program that I’m porting to QNX6 that exhibits a problem
BC > with ofstream. The program was quite large but I was able to trim it
BC > down to the following:

BC > ============================
BC > #include <fstream.h

BC > ofstream outfile; // this would get opened subsequently

BC > int main ( )
BC > { return 0; }
BC > ============================

BC > This compiles OK but if I try to run it it crashes with a SIGSEGV.

I’ll need to see exactly how you compile and link.
I tried cc/qcc/QCC -o tt tt.cc and I can’t get the segv.

BC > If I change the #include to include (no ‘.h’), it won’t even
BC > compile. Not sure why?

Without the .h keeps all those symbols in the std namespace.
Take a look in the Dinkum docs under fstream.h

BC > I tried linking against both gpp and cpp libs.

New information:

This fails if compiled & linked with gcc_ntox86 or gcc_ntox86_cpp. But
it does work as expected using gc_ntox86_gpp. I would like to use Dinkum
(_cpp). What must I do to make that version work?

BTW, what is the difference between gcc_ntox86 and gcc_ntox86_gpp?

Dinkum vs gnu, different headers, different libs, possibly different
defines. Try
qcc -Vgcc_ntox86 -o tt tt.cc -vvvvvvv
vs
qcc -Vgcc_ntox86_gpp -o tt tt.cc -vvvvvvv

4

Garry Turcotte <garry@qnx.com> wrote:
GT > Bill Caroselli wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote:
BC > I have a QNX4 program that I’m porting to QNX6 that exhibits a problem
BC > with ofstream. The program was quite large but I was able to trim it
BC > down to the following:

BC > ============================
BC > #include <fstream.h

BC > ofstream outfile; // this would get opened subsequently

BC > int main ( )
BC > { return 0; }
BC > ============================

BC > This compiles OK but if I try to run it it crashes with a SIGSEGV.

GT > I’ll need to see exactly how you compile and link.
GT > I tried cc/qcc/QCC -o tt tt.cc and I can’t get the segv.

OK. My makefiles, and hence my command lines, are a mile long, but I
finally narrowed it down to the offending parameter.

If I compile with ‘-fshort-enums’ and -Vgcc_ntox86_cpp, then it
compiles OK but I get the SIGSEGV when I try to run it.

I know that most of the streams library is implemented using templates
but perhaps some of it is not, so I can certainly understand why this
makes it fail.

I am using -fshort-enums because I have many enums where there are just
a few values defined and that enum is included inside of a struct, and
I want the size of that enum in the struct to be only 1 byte.

I.E.

enum my_enum
{
one = 1,
two = 2
};
struct my_struct
{
my_enum e;
} ms;

This is done to share communications records with other systems where
I can’t just increase the size of the enum.

Is there a way to achieve what I need to achieve?

5

enum my_enum
{
one = 1,
two = 2
} attribute((packed));

should do what you want

I am using -fshort-enums because I have many enums where there are just
a few values defined and that enum is included inside of a struct, and
I want the size of that enum in the struct to be only 1 byte.

I.E.

enum my_enum
{
one = 1,
two = 2
};
struct my_struct
{
my_enum e;
} ms;

This is done to share communications records with other systems where
I can’t just increase the size of the enum.

Is there a way to achieve what I need to achieve?

6

Garry Turcotte <garry@qnx.com> wrote:
GT > enum my_enum
GT > {
GT > one = 1,
GT > two = 2
GT > } attribute((packed));

GT > should do what you want

OK. Looks great, but . . .

I tried it on my header files and in almost every case it reported:
warning: ‘packed’ attribute ignored
and
semicolon missing after declaration of ‘xyz’

I tried a small program with an enum and it only reported the:
semicolon missing after declaration of ‘xyz’
error

I checked the GNU GCC manual (section 4.30 “Specifying Attributes of
Types”, the paragraph starting “packed”) clearly states that this
should work.

7

Bill Caroselli wrote:

Garry Turcotte <> garry@qnx.com> > wrote:
GT > enum my_enum
GT > {
GT > one = 1,
GT > two = 2
GT > } attribute((packed));

GT > should do what you want

OK. Looks great, but . . .

I tried it on my header files and in almost every case it reported:
warning: ‘packed’ attribute ignored
and
semicolon missing after declaration of ‘xyz’

I tried a small program with an enum and it only reported the:
semicolon missing after declaration of ‘xyz’
error

I checked the GNU GCC manual (section 4.30 “Specifying Attributes of
Types”, the paragraph starting “packed”) clearly states that this
should work.

Neat. It only works for C code, not C++
(it acts the same with gcc on redhat)

You’ll have to specify the field width explicitly.