DDE / random errors

I particularly like this kind of problem:

“c.mhttp”, line 61: Error: <argument 1 to ’close_socket’>: implicit cast of pointer to non-equal pointer

The error is in the function read_download_headers which is defined as:

int read_download_headers( FILE *debug, struct Download *download_struct )

and the function call line is:
close_socket( download_struct ) ;

close_socket is defined as:

int close_socket( struct Download *download_struct )

OK so…
struct Download *download_struct is not the same as:
struct Download *download_struct

sometimes you have to love C compilers!

Yeah, I hate complicated pointer stuff…

But I think the compiler might have a point.

…some rubbish deleted as it was wrong…
(…the moral is easy – don’t try to help with complicated stuff when you’re tired and fed up and are thinking more about your pillow than what you’re typing…)

I think that’s what is going on. I reserve the right to be utterly wrong. Entire books have been written in the intricacies of C’s concept of pointers. :-)

PS: typedef struct ...?

DISCLAIMER: This message represents the official view of the voices in my head.

Confession: When I got these sorts of errors, I would first try swapping . and ->, and then try again. If it still didn’t work, I’d copy it into Xcode and tell it to fix it for me. Coming from a C# background I could be blissfully ignorant of pointers!

As time has gone on I’ve become better at figuring it out myself, but the problem in this thread has me baffled :)

Given that read_download_headers and close_socket have exactly the same declaration of “struct Download *whatever” I fail to see your argument Rick.

I always typedef things like this to keep down the confusion. I never have “struct” appearing in my function declarations.

What’s more bizarre I’m using identical function definition configurations and calling it in those functions in exactly the same way in other libraries. They work and compile fine.
I don’t quite follow what Rick is saying, but I get where I need to go… use typedef.
I’ve not used it before, but after a quick glance around it looks like it’s main point is like Matthew said, to avoid confusion.
I’ve seen typedef used a lot over the years and always wondered what it’s practically used for, guess it’s time to find out!
Also I’m confused, so using typedef sounds like a good idea if it keeps down the confusion ;-)

I think anyone who deals with pointers has to have voices in their head, isn’t that what pointers do (create voices in your head)?
(No…not that way.. yes that’s it… no there… ah yeah that’s it…hang on what about….)

Appreciate the help! Especially as I’m going to have a lot more structures and pointers to structures.
But I want to avoid pointers to pointers, I’ve been there many years ago – not where I want to go ever again! At one point I used pointers to pointers to pointers to pointers and I seem to recall I understood how it all hung together – why would anyone want to understand that is beyond me!

sometimes you have to love C compilers!

I wouldn’t expect the compiler to be wrong which means that you haven’t given us enough information to diagnose the problem – or typed it into your post wrong. If you didn’t copy and paste it’s easy to go code blind with your own code and see what you think you wrote rather than what you actually wrote.

I don’t quite follow what Rick is saying

Forget about that he’s wrong.

typedef sounds like a good idea

typedefs are a good idea but won’t help if your confusion is with pointers. Like Matthew I always typedef my structures it avoids accidentally missing the struct keyword in declarations – and it makes the code easier to read I think.

Forget about that he’s wrong.

I did say I might be. Okay, fine, moving on…

What is clear is that the compiler is objecting to the type of struct in the definition and what is being passed. I considered it might be a pointer to pointer issue. Clearly not.

The next suggestions:

• Is what is typed exactly what is in the code? The compiler doesn’t seem to think this is the case so it should be checked in detail.
• Is there a local variable of a different type with the same name? Given the name this doesn’t seem so likely. In one of my programs I have a global struct called “area”. If I create an int in a function and call it area, that takes precedence over the global struct leading to this sort of problem.
• Are you passing the struct as the struct itself or by &struct?

Just some ideas…

Pointers in C. You need them to express complex datatypes in C, of course. But actually there are lots of languages where those datatypes, any datatypes, can be described just as adequately, and a lot more easily, without pointers (or explicit memory references) of any kind. Lua is a case in point. I mention this because I suspect that over-exposure to C gets people to assume that the C way is the only way.

OK, that explains what typedef is. My point was more to laugh at some compiler/interpreter errors etc.
Clearly there is a problem, but the problem is not an implicit cast of pointer to non-equal pointer.
Both pointers are equal, they are pointers to the same struct type.
So from my perspective the compiler is lying to me.
However, that doesn’t mean that there isn’t a problem – there clearly is, I just can’t see it yet.
My guess is something along the lines of what Rick suggested in his last second suggestion, i.e. a somehow duplicate definition.
For the moment I’ve just commented out the close_socket call and put a note in to fix it.
Things are getting shifted around a lot at the moment to clean up and sanitise the code, so it’s likely to get fixed as part of that cleanup.
I’ve just replaced three pages of case statements, now the case statement is only a few lines and actually readable.

Do people still use lint?

I particularly like this error when using ansible:

We could be wrong, but ….

Clearly there is a problem, but the problem is not an implicit cast of pointer to non-equal pointer.
Both pointers are equal, they are pointers to the same struct type.

From what you told us that doesn’t follow at all. If you have:

 1 #include <stdio.h>
 2
 3 struct Download
 4 {
 5         int a;
 6 };
 7
 8 void close_socket(struct Download* download_struct)
 9 {
10 }
11
12 int read_download_headers(FILE* debug, struct Download* download_struct)
13 {
14         if (0)
15         {
16                 int* download_struct;
17                 close_socket(download_struct);
18         }
19         return 0;
20 }
21
22 int main (void)
23 {
24         struct Download download_struct;
25         read_download_headers(0, &download_struct);
26         return 0;
27 }

Then you will get the error you describe. Without seeing the rest of your code we can’t know where you have gone wrong.

Hi Colin,

It’s pretty much as you describe above.
Surely..
in the main function &download_struct is a pointer to struct Download.
in the read_download_headers, by definition download_struct is a pointer to struct Download.
You are passing it a pointer to struct Download.
So it’s saying:
a pointer to struct Download is not the same as a pointer to struct Download.

I assume the problem is I’m about 1/2 way through abstracting the code.
What is weird is that the rest of the code, that works in the same way and is called from the same points compiles fine.
i.e. I have similar functions (just different names) that call close_socket with identical input and output variables.

e.g. if you changed read_download_headers to read_socket, write_data_to_file, open_socket amongst many functions then it compiles and works fine.
The only difference is tha read_download_headers passes the FILE *debug parameter to it.

So that seems to indicate a=b and a!=b depending on how the compiler “feels” at the time.

I could largely accept that one is not the same as one, that would suggest I’m misunderstanding something.
But when one is not the same as one and the same as one is when I get confused.

The conclusion I draw is that I’m totally misunderstanding how you pass pointers to a function.

I’m moving to use pointers to functions everywhere at the moment and my code needs simplifying. So I’m very confused why virtually the same code works in one place and not in another, but given my programming skill not totally suprised.
Perhaps it’s just tiredness?
Once I finish migrating and cleaning up my code it may make sense… or just work.

in the main function &download_struct is a pointer to struct Download.

Aha… The ampersand raises its ugly head.

(struct) download_struct is the structure.

*download_struct is a pointer to an instance of the structure. There is no structure, that’s possibly somewhere else, and this is what points to it.

&download_struct is the address of the element. I say ‘element’ as I think in the first case (the actual struct), it is the address of the struct, but in the pointer, it is the address of the pointer…

So, no, the compiler is right. &something != something

(^_^)

I’ve numbered the lines in the above program to make it easy to refer to.

At line 25, &download_struct is not a struct Download* because line 25 specifies the second parameter of read_download_headers to be a struct Download* but because line 24 declares download_struct to be a struct Download. If the second parameter to read_download_headers was a char* then you would get the error you get because a struct Download* passed to the read_download_header isn’t the char* the function expects.

At line 16 of the program I’ve declared a new variable download_struct to be an int* so when it is used in close socket download_struct is no longer the struct Download* that close_socket expects and so gives an error.

The easiest way to find the problem is to search for download_struct and see if you have declared a new variable with that name before calling close_socket. The problem you have is the download_struct you pass to close_socket isn’t the download_struct parameter to read_download_header.

struct Download
{
        int a;
};

struct Download download_struct; // this is the static memory allocation

struct Download* download_struct_pointer = &download_struct;
struct Download* fred = malloc(sizeof(struct Download)); // dynamic memory allocation

ie a pointer is the address of a structure. fred and download_struct_pointer are both struct Download* and can be used without casting in any function which has a struct Download* parameter.

For fun and chocolate…

#include <stdio.h>
#include <stdlib.h>

// The "meh" structure
typedef struct
{
   int a;
   int b;
   int c;
} mehdef;


int  main(void)
{
   // Define an instance of the "mehdef" structure, call it "meh"
   mehdef meh = { 0, 0, 0 };

   // Define a pointer to the "mehdef" structure, call it "mehptr"
   mehdef *mehptr = NULL;

   // The actual "meh" structure, the first one, exists.
   meh.a = 1;
   meh.b = 2;
   meh.c = meh.a + meh.b;
   printf("meh    is %d, %d, %d\n", meh.a, meh.b, meh.c);

   // The second one, the pointer, does NOT yet exist.
   // We must make it so.
   mehptr = calloc(1, sizeof(mehdef));
   if (mehptr == NULL)
   {
      printf("Mem alloc failed.\n");
      return(0);
   }

   // Now we have done this, the pointer version "exists".
   mehptr->a = meh.a << 1;
   mehptr->b = meh.b << 1;
   mehptr->c = meh.c << 1;
   printf("(mehptr's values should each be twice the above)\n");
   printf("mehptr is %d, %d, %d\n\n", mehptr->a, mehptr->b, mehptr->c);

   // Actually, in truth, the pointer version has always
   // existed, but prior to having some memory allocated,
   // mehptr pointed to zero. That's part of what is going
   // wrong with some software on the high page zero version
   // of RISC OS. If the pointer points to NULL (0) and has
   // not correctly been set to where it is supposed to
   // point to, then trying "mehptr.a = xxx" would try to
   // write xxx to address &00000000. Oops!

   // Now let's try something else. Get rid of our memory claim.
   free(mehptr);

   // And instead, set mehptr to *point* at meh.
   mehptr = &meh;
   // note the '&'; just using "meh" would result in the value
   // of meh.a being assigned to mehptr, this would clearly be
   // wrong; so '&' tells the compiler we want to know where
   // the meh structure *is*. 

   printf("(these should both be the same)\n");
   printf("meh    is %d, %d, %d\n", meh.a, meh.b, meh.c);
   printf("mehptr is %d, %d, %d\n\n", mehptr->a, mehptr->b, mehptr->c);

   // Now, we change meh.
   meh.a = 0x43495045;
   meh.b = 0x4E495720;
   meh.c = 0x00212121;
   printf("(these should both be the same, again)\n");
   printf("meh    is %X, %X, %X\n", meh.a, meh.b, meh.c);
   printf("mehptr is %X, %X, %X\n\n", mehptr->a, mehptr->b, mehptr->c);

   // And finally, deal with the message.
   printf("%s\n", (void *)&meh); // yikes!

   return(0);
}

 mehptr = &meh;
   // note the '&'; just using "meh" would result in the value
   // of meh.a being assigned to mehptr

No it wouldn’t you would get a compiler error because a mehdef structure isn’t a mehdef pointer. Compiler errors are there to catch this kind of error that can be detected at compile time.

It would be interesting to know which is the most common bug, dereferencing a NULL pointer or dereferencing a freed pointer. Zeropain will only catch the former.

No it wouldn’t you would get a compiler error

He’s right (obviously, duh me).
I was basing what I said on the behaviour of printing out the value of meh and &meh. I forgot that the compiler would object to that assignment. Rightly so, as the assignment is gibberish. ;-)

It would be interesting to know which is the most common bug, dereferencing a NULL pointer or dereferencing a freed pointer.

Given some of the code I’ve seen, I would suspect dangling pointers are the most common.

Zeropain will only catch the former.

The irony of the situation is, funnily enough, that ROOL could probably have made their high vector change without most people noticing by simply stealing 32K and mapping it in at &0 as junk memory. Few things should be looking at the kernel data, nothing should be directly altering the processor vectors, and stuff that does dodgy reads and writes where it shouldn’t will carry on instead of going crashy-crashy.
Okay, it isn’t the way to get broken software fixed, but it is a way to get the sensitive bits out of the way with minimal disruption to everybody else…

Thanks Colin, that does explain it. Although it is kind of weird. It’s understandable though, but it is essentially the compiler saying 1=1 and 1!=1 – but only because I’ve changed the definition of 1 somewhere..no wonder I was having trouble in my head!
It’s probably lucky that it happened at this exact moment, as I’m just in the process of restucturing al this and removing all global variables.