Migration to OS4

I get the following error compiling for OS4
'struct Library' has no member named 'FirstScreen' for the line
sc2 = IntuitionBase->FirstScreen;
How do i have to change this??

Thanks for any help


Joseph

@JosDuchIt

Either change the code to:

sc2 = ((struct IntuitionBase *)IntuitionBase)->FirstScreen;

or use the __USE_BASETYPE__ define that's documented in the os4_migration_guide.pdf in the SDK (add -D__USE_BASETYPE__ to the commandline when compiling).

@salass00

Thanks for the solution.

I did read about the __USE_BASETYPE__ possibility, but how to do it in 'OS4' mode was what i was looking for. I was not that sure about what __USE_BASETYPE__ acheaved neither.
I am?not a C programmer, just struggling my way through this OS4 migration.

Joseph

Hello,

I get an error "two or more data types in declaration specifiers"
The compiled file is gui.c, which directly or indirectly includes all other files as .h files, even though most contain also specific function sets .
No makefile is used (yet)

gui.c includes
globals2.h in line 13
gui_protos.h 18
Font.h 86
and many other header files containing specific functions

globals2.h includes def/glob_GCmain.h

which defines the MyFont structure as:


struct MyFont // in def/glob_GCmain.h
{ UBYTE fontname[36];
struct TextAttr fta;
struct TextFont *ftf;
struct MyFont *next;
};


gui_protos.h prototypes the erroneous function??? as :
struct MyFont * openfont(UBYTE * , LONG , BOOL , UBYTE * ); // in gui_protos.h

The litigious function is defined in Font.h as:

int struct MyFont * openfont(UBYTE *name, LONG height, BOOL report, UBYTE *repstr) // this line gets the error " two or more data types in declaration specifiers"
{
struct MyFont ft, *fs;

// check if font exists, and return that if found..
for (fs = gd->topfont; fs; fs = fs->next)
{ if ((stricmp(fs->fta.ta_Name, name)==0) && (fs->fta.ta_YSize == height))
return (fs);
}

memset (&ft, 0, sizeof(ft));
ft.fta.ta_Name = name;
ft.fta.ta_YSize = height;

// open the font first, to make sure we can, then store it..
ft.ftf = (struct TextFont *)OpenDiskFont (&ft.fta);
if ((ft.ftf==NULL) && report)
{ Printf ("* %s: Could not open font %s - %ld", repstr, name, height);
return (NULL);
}

return (addfont(&ft.fta, ft.ftf));
}


There are other functions in Font.h using the MyFont structure and not raising this error.

Any help much appreciated

Joseph

@JosDuchIt

Just remove the "int" from the function prototype:

Quote:

@JosDuchIt

You are getting the error because function openfont() is declared as having two types of return: integer, and a pointer to struct MyFont. Only one function return type is allowed in C.

@trixie

Of course... Well i am blushing not having seen this.
Thanks a lot

Joseph

@JosDuchIt

No problem, I've made a good lot of stupid programming mistakes myself

@JosDuchIt
You could always use a decent programming language (which actually highlights the code causing the error), rather than put-up with cryptic error messages from C

@ChrisH

Except in the first instance it does:

struct Library' has no member named 'FirstScreen' for the line
sc2 = IntuitionBase->FirstScreen;

It is telling you that IntuitionBase is being treated as the generic structure "Library" rather than the specific one required, and it shows the line.

Besides, it isn't the language that provides cryptic messages, it is invariably the compiler. Of course that is a factor of the programming language itself being incredibly powerful and thus hard to pattern recog errors to a specific problem but reduce the power and it might end up being less of a useful language, or more bland in domain.

Like, oh, BASIC ... or E

@DaveP Quote:
No, it's just lazy programming IMHO. Given the similarity(*) between E & C (except that E is more powerful...), I don't doubt that a C compiler _could_ highlight the actual code causing the error, as well as providing more meaningful error messages.

(* = programming model, not syntax)

@ChrisH

Lazy programming? Well think about it a little longer...

Say you had this sequence:

struct Library * mylib;
mylib = OpenLibrary("intuition.library");
mylib->FirstScreen;

Now OpenLibrary is polymorphic, in that it returns the highest base "class" (even though it is a struct). We have declared mylib as a struct Library pointer which is the base class.

The code will compile up to where we try to access field FirstScreen, which does not exist in struct Library but might in say, struct IntuitionLibrary (making this up as I go along as I don't have the time to fart around with autodocs this morning).

The ideal compiler message might be:

"Look you plank, you are trying to access FirstScreen which is on struct IntuitionLibrary.. you need to cast it to the right structure so I can see what offset the field "FirstScreen" applies to."

But how can the compiler know? As far as you are concerned, you are telling it what you want to use. At this point should it hunt through all the structures that might be defined and say, look bucko, FirstScreen isn't in struct Library it is in struct IntuitionLibrary?

But what if you are the definer of struct Library in the first place? Would you not then prefer a message saying "Oh, you didn't define FirstScreen in struct Library yet but you tried to use the field!"?

There is a limit to how useful extra intuitive messages are. In this case the safest thing to report is that FirstScreen isn't a member of struct Library, and leave it at that. Anyone who understands what a structure is, will think oh hang on, should I not be looking for a different structure. If I can't control what the structure is, perhaps I should consider typecasting.

Some might then say, heck, well the language should have weaker typecasting. Well, do I really need to spell out the runtime dangers of weakly typed programming? Any seasoned programmer will doubtless already have hit them.

Compilation messages are our friends, not our enemies. They help us smooth out problems that would be harder to spot at runtime. What MIGHT be helpful is a lookup guide that sayes when the compiler reports this, this is the error taxonomy that you should be looking for.

@ChrisH

Hi Chris ,

I still have to look at portableE, which i wil do in time. As it is now i just am working on a program i didn't write and which i want to use under os4.1 in the debug mode so i can get rid of a number of problems in the 68k emulation mode. I guess a number of them which i never experienced under 68k orAmithlon could be due to the emulator;

The compiling errors still remaining have to do with hooks. I have included the SDI headers and hope this will prove the easier way to taccle this.

Joseph

@DaveP

And of course, you could always use an editor that actually highlights the line, and even sticks the error in a hintinfo :)

*shrug*

Simon

@DaveP
Perhaps my fault, but you didn't understand my complaint: I was talking about JosDuchIt's SECOND post, where he has the "two or more data types in declaration specifiers" error, NOT his first post where clearly (as you point out) the compiler can hardly be more helpful (unless it starts guessing what you intended to do).

I was mainly complaining that C compilers (and I guess even most IDEs) don't highlight the specific part of the line that is the cause of the error. Which can lead to some people misunderstanding the cause of the error, such as JosDuchIt not realising that "int" was the cause in the line beginning "int struct MyFont * openfont(".