I'm getting a lot of these warnings when using GCC under OS4:

assignment from incompatible pointer type

and

passing argument n of 'functionname' from incompatible pointer type

and want to know what GCC command line option(s) will suppress them. Thanks.

Last edited by Minuous on 20-Nov-2014 at 03:15 AM.

@Minuous

Don't supress them, fix them.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

I've checked the code and it's fine, there are many hundreds of these warnings and it's not worth "fixing" them all individually.

It's cases like:

AddChild, gadget[gid] = ButtonObject, ..., TAG_DONE

where gadget[] array is defined as struct Gadget* gadget[GIDS];

The code works fine, and doesn't cause any warnings on OS3 nor MOS. Defining the gadgets as Object* isn't really viable either as it would necessitate a lot of needless casting elsewhere in the program. Most of the time the pointers are just being used as handles anyway, and pointers on the Amiga are always 32 bits, the warning is just a portability warning for the largely theoretical case on hypothetical systems where different pointers are different lengths.

I could use -w to switch off all warnings, however some warnings are actually useful. Just not these ones.

Last edited by Minuous on 20-Nov-2014 at 03:18 AM.

@Minuous

The ButtonObject macro is returning an Object * so you need to cast it to struct Gadget *.

Tedious maybe, but switching off the warning , hides the real error when it occurs.

Though to be honest I gave up trying to get code to be warning free on both 68k and AmigaOS 4


I've looked through the gcc.pdf and I honestly can't see the specific option to turn if on, it's enabled by -Wall.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

I think to be "pedantic" it's switched on by -pedantic which in turn is switched on by -Wall

-pedantic switches on all warnings defined in the ISO spec.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

I'm not currently using -Wall. These warnings appear to be enabled by default, and unable to be turned off, except with the -w option.

@Minuous

I second broadblues' recommendation to fix your code instead of suppressing the warning.

Quote:

I've checked the code and it's fine, there are many hundreds of these warnings and it's not worth "fixing" them all individually.

Actually, it is worth going through and fixing every one of them. If you suppress the warnings and then accidentally really do assign an incompatible object to a pointer (really easy to do), then you'll have no idea why on earth your code is crashing. You won't know where to look.

I'd go a step further, and recommend compiling with -Wall set, and making sure that the code produces zero warnings. This might get a bit annoying at times, but it will help you to catch bugs faster. The warnings are there for a reason...

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Minuous

Quote:

Defining the gadgets as Object* isn't really viable either as it would necessitate a lot of needless casting elsewhere in the program.

This is jumping to premature conclusions, and a little explanation is needed:

At some point in the OS4 SDK, gadgets and images based on BOOPSI were re-defined as pointers to Object (instead of pointers to respective structs). This was done in order to support OOP principles, and to remedy Commodore's original design flaw. In OOP, an object is just a handle, an opaque pointer that does not represent any particular data. Commodore disrespected this principle and introduced BOOPSI gadgets and images as pointers to data structures.

Their motivation is clear: they wanted to integrate BOOPSI with the original Intuition, where GUI elements were based on data structures. The result was a hybrid, half-OOP system that allowed for certain unwanted practice. For example, programmers were able to acquire/modify data via the object handle (by peeking/poking the particular data structure), instead of calling the OM_GET/OM_SET methods as they should.

Having ReAction (which is now part of BOOPSI), integration with the old Intuition is no longer needed, so reference to its data structures is pointless. We can head for a full OOP system. The change in the OS4 SDK reflects this, and promotes correct programming practice.

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@Minious

To quote Hans:
Quote:

Actually, it is worth going through and fixing every one of them. If you suppress the warnings and then accidentally really do assign an incompatible object to a pointer (really easy to do), then you'll have no idea why on earth your code is crashing. You won't know where to look. I'd go a step further, and recommend compiling with -Wall set, and making sure that the code produces zero warnings. This might get a bit annoying at times, but it will help you to catch bugs faster. The warnings are there for a reason...

It may look a tedious job and very annoying in the beginning, but in the end it pays of big time as it reduces the chance of persistent and far more annoying bugs, which you have to look for AFTERWARDS, while your program seems to be running quite ok, sometimes, but some other times quite not so. It is far better to spend time on producing good code then spend time on bughunting, after which you still have to rewrite your code anyway.
On a different note but of a similar nature is the need for checking results whenever and wherever applicable. Some coders use the term 'laziness' for an excuse to not check results. Replace 'laziness' with 'stupidity'.

My 2 cents, but bite the bullet and never look back.

OldFart

_________________
More then three levels of indigestion and you're scroomed!

@Minuous

Quote:

Defining the gadgets as Object* isn't really viable either as it would necessitate a lot of needless casting elsewhere in the program.

Only for gadget centric intuition calls like SetGadgetAttrs() for instance and you can make this less work by defining a macro for it like so:

#define GA(o) ((struct Gadget *)(o))

@Trixie

This (Gadget/Image structures as part of a BOOPSI object) wasn´t a "design flaw" at all. It was just a logical extension to go on to real object oriented GUI (and it was a quite brilliant thing for its time, btw). It was definetly not the fault of C= that some guys used this "flaw" in a way definetly not recommended by C= (just take a look into BOOPSI docs. There are several warnings about this).

You could use C++ objects in a very similar way if you want (and the compiler lets you do these things, which is a different story. But if you really want to do such things, you might find a way). So is it a "design flaw", too?

@minous

Use the correct variable types and/or type casts for the function calls you get warnings for. It heavily depends on the used function, if an Object or Gadget pointer is required (and you as the software developer should know which type is needed). The compiler just tries to be nice in reminding you that you might do things that could go wrong using the wrong type of pointer.

Regarding BOOPSI/ReAction, if you don´t plan to support plain Intuition GUI functions (and I don´t know any reason to do so if you use ReAction), you should use Object * arrays instead of Gadget * and/or Image * arrays. Eliminates a LOT of warnings in one go

It´s not very hard to kill all those warnings, it´s just a matter of programming discipline. All of my programs I do with the OS4.1 SDK are free of compiler warnings

Edit: I should repeat it: "(and I don´t know any reason to do so if you use ReAction)". If there are "too much type casts needed" when using Object instead of Gadget, you should think about your program design. If you heavily mix BOOPSI and simple Intuition Gadgets, the program design is really (really!) bad.

Last edited by whose on 20-Nov-2014 at 12:33 PM.

@whose

No, the program design is just fine. If you change struct Gadgey * types to Object * type you get nowhere. It is going to throw warnings when compiled to 68k or MorphOS target so it is completely pointless.

Howevet, one solution to suppress warnings would be using genetic APTR everywhere. There is way too much typing and manual casting in Amiga coding already.

Last edited by itix on 20-Nov-2014 at 02:24 PM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Quote:

No, the program design is just fine. If you change struct Gadgey * types to Object * type you get nowhere. It is going to throw warnings when compiled to 68k or MorphOS target so it is completely pointless. Howevet, one solution to suppress warnings would be using genetic APTR everywhere. There is way too much typing and manual casting in Amiga coding already.

The solution is simple really, if you want store the results of the ButtonObject macro in an array of struct Gadgets that fine, (its what I do) simply cast it to (struct Gadget *) that way no warning is issued at the point of asignit to the array and no warning will be issued when using that array element in a SetGadgetAttrs() type call.

Then the only time you need to cast to an Object is in a generic BOOPSI function like GetAttrs()

I'm not sure why the warnings are only emited for AmigaOS4 SDK, did the include drop a cast, or did the compiler get fussier?

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

OK looking at the includes for 3.5 verses 4.1 it looks like the BOOPSI functions now take a pointer to Object, rather than an APTR.

externally an Object is

typedef ULONG Object;

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Minuous

I've managed to earn a living for the past 20 years by fixing C code that doesn't contain "unnecessary" type casts.

But as far as your best interest, I will join the pile-on: you will be happier in the end if you address these warnings up front.

_________________
"Unix is supposed to fix that." -- Jay Miner

@broadblues

Quote:

The solution is simple really, if you want store the results of the ButtonObject macro in an array of struct Gadgets that fine, (its what I do) simply cast it to (struct Gadget *) that way no warning is issued at the point of asignit to the array and no warning will be issued when using that array element in a SetGadgetAttrs() type call.

That works.

Why I just dont like it is that when you have casts all over place it becomes so common that it obfuscates code and is not improving code quality anymore.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Minuous

Without taking sides in this particular case, here are instructions for disabling any errors from warnings you might get without affecting other types.

Personally, I usually use -Wall -Wextra -Werror, and then whitelist some harmless warnings like -Wno-error=unused-function

Simply add -fdiagnostics-show-option to compile args, and gcc will give a keyword for each warning / error type you get, that can be used with -Wno-error - not sure if there is no-warning equivalent.

@Jupp3

My earlier statement that the warning was added by -pedantic or -Wall seems incorrect, I just made a quick test case to test your -fdiagnostics-show-option suggestion and find the warning is on my default.

-fdiagnostics-show-option seems to add no extra info in this case.

9.RAM Disk:> gcc -o ram:testit -fdiagnostics-show-option test.c 
test.c: In function 'main':
test.c:5: warning: assignment from incompatible pointer type

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@itix

Quote:

Why I just dont like it is that when you have casts all over place it becomes so common that it obfuscates code and is not improving code quality anymore.

Agreed. That's why I think continueing to Gadgets for gadgets amd Image for images etc is the best approach. This helps avoid passing the wrong type of BOOPSI object, which since there is neither compile time (beyond type warnings) nor runtime checking is often fatal.

Taglists are another source of such "casting noise" as you get warnings about something you really did mean to do, such as pass a STRPTR as a ULONG

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

OK, I'm going through the code and adding the hundreds of casts necessary...

@Trixie:

There are situations where there is no suitable OM_GET/OM_SET method available. Eg. to ascertain where the left edge of a gadget is, you need to look at the LeftEdge field in the Gadget structure. (Unless there is some other equally efficient way of doing it of which I am unaware?)

@whose:

I'm not mixing simple gadgets with ReAction ones, the program is 100% ReAction-based for its GUI. The hundreds of casts are required because there are hundreds of gadgets being created.

As a general comment about compiler warnings, just because a particular warning may indicate a real problem, or even definitely indicates a real problem, doesn't mean I want to see the warnings every time I run the compiler, as there are so many that they just scroll out of the window faster than I can read them. (GCC is buggy because it doesn't use stdout correctly, so redirection isn't possible via the "greater than" operator, and the default OS4 console is awful (no scrollbar, no way of logging its output).) It's odd that most of the more important warnings can be turned off but not the less important ones, if anything it should be the other way around.

Last edited by Minuous on 20-Nov-2014 at 07:51 PM.