Thread: Help with pointers please.

I have struggled for a very long time with pointers in C. I've never had a good concept and whenever I've written a program, I hate to say it, but I've pretty much just tried a bunch of trial and error type things until it worked. As you can imagine, this causes big problems when you don't have a fundamental understanding of how the code works.

With that being said, I was hoping someone could recommend a good free source on pointers in C. Even though I understand a little bit about them, I'd like a source that assumes I have no idea what a pointer is and fully explains everything.

I know this is going to sound sad, but I'm writing a program and I need to check the return value of a function. The function returns NULL if no COM ports are found on the system. I seem to not be able to understand why this doesn't work:

Code:

    if(sp_list_ports(&ports)==NULL) {
        printf("We've found no com ports.\n");
    } else {
        for(i = 0; ports[i]; i++) {
            printf("Found port: '%s'.\n", sp_get_port_name(ports[i]));
        }
    }

The problem is in the if statement. When I try to compile, I get a warning saying: warning: comparison between pointer and integer
I believe on this system, NULL is a macro defined as 0. If I type something like:

Code:

    if(!sp_list_ports(&ports)) {...

There's no error. Now, if NULL is really set as 0, how come when I use:

Code:

    if(sp_list_ports(&ports)==0) {...

We get no warning? I can compare NULL to 0 and get no error. This leads me to believe there's a problem with comparing it to the pointer.

Could someone help me please? Thank you.

I think I made an error in my previous post. I think NULL on this MinGW compiler is defined as ((void *)0).

Originally Posted by migf1

If that's the sp_list_ports() you are using, then it does not return a pointer. It returns an enum value (defined here: libserialport: libserialport.h Source File).

Okay, so my mistake was thinking NULL was set to 0. I knew sp_list_ports returned SP_OK on success, which was defined as 0 (I looked at the source as well). I thought NULL was defined with 0. Thank you for your help. Here's the new code. This seems to work.

Code:

    /* Get a list of serial ports on the system, if any, and store them in pointer ports */
    sp_list_ports(&ports);
    if(*ports==NULL) {
	printf("0 COM ports found.\n");
    } else {
        /* We found some COM ports, lets print them. */
        for(i = 0; ports[i]; i++) {
            printf("Found port: '%s'.\n", sp_get_port_name(ports[i]));
        }
    }

Originally Posted by Cat

A quick run-down on what a pointer is:

A pointer is just a special type of numeric variable, designed to store a memory address. So you can manipulate the pointer itself (the memory address stored), and you can also manipulate the contents of that memory address, be "dereferencing" the pointer.

Take a look at this thread for some ideas on what a pointer is and how it works:
changing variables with pointers

Thank you! When I wake up a little more, I'll read the whole thing. I majored in Computer Science but I went into the Marine Corps and had some damage to the head while I was in there. My memory gets a little messed up sometimes. It seems to take extra time to memorize new stuff and the old stuff seems a little blurry. If I can get a good fundamental understanding of all these pointers, I think I'll be good.

I have trouble with this whole dereferencing thing. Like when do you dereference a pointer? When don't you? If you notice, in my code, with the if statement, I have to a * in front of ports. My understanding (from what I remember from college), this means compare what's stored at wherever port points to to NULL and if they're equal, print 0 com ports found. If I didn't have the * in front of it, I'd just be comparing NULL to a memory address or something.

I'm sure the link you sent will correct all my misinformation and reinforce all the information I once learned. Thanks!

Thanks Migf1. I'll be sure to check it out. The code seems to work. If I have no COM ports, it prints 0 COM ports found, if it finds them, it lists them. I looked at the source code, serialport.c, and saw what happened if something went wrong. I could be wrong though. If I didn't have the * in front of ports (to check the first element), when there where 0 COM ports found, the code didn't work. It think there was a COM port. I'm lucky in the sense that I have a USB to serial adapter on this PC, so I can easily add / remove the serial port for testing purposes.

I tried creating separate functions for the port stuff, like enum_ports, print_ports, free_ports. The compiler didn't like my code at all.

I first tried this:

Code:

int enum_ports(struct sp_port **ports);    /* Function to enumerate COM ports on the system */
int print_ports(struct sp_ports **ports);  /* Function to print the enumerated ports found on the system */
int free_ports(struct sp_ports **ports);   /* Function to free up memory from the libserialport malloc calls */

That didn't work. The compiler complained a lot, with messages like:

Code:

In file included from src/main.c:12:0: src/prototype.h:7:23: warning: 'struct sp_port' declared inside 
parameter list int enum_ports(struct sp_port **);  /* Function to enumerate COM ports on the system */

Then I tried this:

Code:

int enum_ports(struct sp_port **ports);    /* Function to enumerate COM ports on the system */
int print_ports(struct sp_ports **ports);  /* Function to print the enumerated ports found on the system */
int free_ports(struct sp_ports **ports);   /* Function to free up memory from the libserialport malloc calls */

From what I was reading, this could be caused by the fact that I have the struct defined in main, like this:

Code:

struct sp_port **ports;	        /* structure to hold COM ports for libserialport library */

Perhaps I need to declare it globally in my main.c file? Before main()... Also, because I'm planning on passing a pointer of type structure ports to the functions, maybe I need an extra asterisk? I guess this is just more proof I still need more reading.

The original forum was nice but a bit confusing at parts because there where questions being asked and it would through me off a bit. Like I was following what was being said, then someone would ask a question with incorrect info, like hey, can I do this? and I'd start confusing what they where trying to do with the correct way. I'm sure this is just a problem that I have. Other people can probably read it just fine. I found some book I started reading, C Programming, A Modern Approach - 2nd Edition, by K.N. King. I've just started from the beginning. Figured I'd fill in the some of the missing caps.

Okay, just a little clarification, after looking at my code above, I noticed an extra s on sp_port. This caused some compiler errors. I created a new project, just a main function and my functions that call the libserialports library functions. It compiles, finds a port, than crashes. So...I've taken a break from that project and started reading up on the pointers...

I have a question. With the link you've given me, it takes about int being the size of 4 bytes on modern systems. I'm assuming the whole article assumes the size of int to be 4-bytes. I want to get into PCB development using PICs or AVRs in the future. int might not always be 4-bytes but I think with the article, the size of the data types might not matter so much.

I've seen stuff before like:

Code:

int *ptr_a;
int* ptr_b;

Are they the same? one has the * with int, one has the star with the variable's name.

Also, if I had something like,

Code:

int** ptr_a, ptr_b;

;
ptr_a becomes **ptr_a and ptr_b because just ptr_b, right? Not *ptr_b with one asterisk?

Thanks.

Originally Posted by Spork Schivago

I have a question. With the link you've given me, it takes about int being the size of 4 bytes on modern systems. I'm assuming the whole article assumes the size of int to be 4-bytes. I want to get into PCB development using PICs or AVRs in the future. int might not always be 4-bytes but I think with the article, the size of the data types might not matter so much.

C only guarantees that 'int' is large enough to hold a value between -32767 and +32767, which means it's at least 16 bits wide. Most 32-bit/64-bit systems have 32-bit 'int'. This just goes beyond the minimum size guaranteed by C.

Originally Posted by Spork Schivago

I've seen stuff before like:

Code:

int *ptr_a;
int* ptr_b;

Are they the same? one has the * with int, one has the star with the variable's name.

They are the same. The spaces are ignored.

Originally Posted by Spork Schivago

Also, if I had something like,

Code:

int** ptr_a, ptr_b;

;
ptr_a becomes **ptr_a and ptr_b because just ptr_b, right? Not *ptr_b with one asterisk?

Thanks.

ptr_a is a pointer to pointer to int, and ptr_b is an int. The asterisks bind to the variable name rather than to the type. That's the main reason I and many others prefer to write such as declaration like this:

Code:

int **ptr_a, ptr_b;

or, better, like this:

Code:

int **ptr_a;
int ptr_b;

to make it clear that the asterisks apply to ptr_a but not to ptr_b.

Originally Posted by migf1

This makes sense only if sp_list_ports() does NOT consider as error the case where no ports are found. Which in turn means that even when no ports are found, the functions allocates the ports array anyway with just a single element, and sets it to NULL. I guess this is an effort to be consistent with the concept of ports being a NULL terminated array of pointers to sp_port structures. No ports found, so the array contains just a NULL as its only element. *ports is the same as ports[0] in our case. Btw, make sure you call sp_free_port_list( ports ) when you are done, otherwise you'll leak memory.

Yes, if I understand the code correctly, if no COM ports are found, it's not treated as an error. This is what makes up the sp_list_ports(...) function.

Code:

SP_API enum sp_return sp_list_ports(struct sp_port ***list_ptr)
{
#ifndef NO_ENUMERATION
    struct sp_port **list;
    int ret;
#endif


    TRACE("%p", list_ptr);


    if (!list_ptr)
        RETURN_ERROR(SP_ERR_ARG, "Null result pointer");


    *list_ptr = NULL;


#ifdef NO_ENUMERATION
    RETURN_ERROR(SP_ERR_SUPP, "Enumeration not supported on this platform");
#else
    DEBUG("Enumerating ports");


    if (!(list = malloc(sizeof(struct sp_port *))))
        RETURN_ERROR(SP_ERR_MEM, "Port list malloc failed");


    list[0] = NULL;


    ret = list_ports(&list);


    if (ret == SP_OK) {
        *list_ptr = list;
    } else {
        sp_free_port_list(list);
        *list_ptr = NULL;
    }


    RETURN_CODEVAL(ret);
#endif
}

NO_ENUMERATION gets set if the developers don't know how to enumerate the COM ports on a system yet, for example, on the Android smartphones. The part that says,

Code:

*list_ptr = NULL;

I took that as we set the first element in the structure to NULL. Then, afterwards, if we find more, we add them to the list. This means that if no COM ports are found, I should be checking *ports to see if it's set to NULL, right?

Originally Posted by migf1

What's the difference between those 2 code snippets? They look exactly the same to me (however, I'm quite tired right now).

You're correct. I copied and pasted but forgot to change the first code. With the function prototypes in the first code snippets I posted, it wasn't supposed to have **ports. I had first tried:

Code:

int enum_ports(struct sp_port **);    /* Function to enumerate COM ports on the system */
int print_ports(struct sp_ports **);  /* Function to print the enumerated ports found on the system */
int free_ports(struct sp_ports **);   /* Function to free up memory from the libserialport malloc calls */

I was almost certain I could do this with function prototypes and was almost certain the second example wouldn't make a difference, you know, replacing ** with **ports. I was correct.

Originally Posted by migf1

This doesn't make much sense, unless you provide more detailed code. The warning you get from the compiler, most likely means that you are using struct sp_ports inside the parameter lists without having previously declared or defined it in that file.

I believe the problem with the code, why the error didn't make much sense, was because there was no , it was struct sp_port **ports;. Two of those function declarations I created use struct sp_ports, instead of struct sp_port.

Originally Posted by migf1

It depends on what you are trying to do. An extra asterisk would be needed if your functions will change the address of the ports array, perhaps by malloc'ing, or reallocing the array. However, judging from the names of those functions, that's not the case, so you most probably don't need an extra asterisk. That's all guesswork for me though, because (despite their descriptive names) I don't know what you are actually doing inside those functions. You need to provide more detailed code.

What I wanted to do was call some custom made functions from main, passing them the struct sp_port **ports; structure, and have those functions do various things, instead of having all the code in main. I actually have a main.c file and then a ports.c file. I wanted, in main, to call my functions in the ports.c file, enum_ports, print_ports, and free_ports, passing a pointer to struct sp_port **ports; to each function. And then have those functions do various things (error checking on the library call that I made, etc).

Originally Posted by migf1

That's an excellent introductory book to C programming. However, what you are dealing with here (with the libserialport and GTK+) require you to have a pretty good grasp of some advanced use of pointers and data structures. I'm not saying that the book will not help you, but afterward you should probably read about (or even better practice) techniques that may be more advanced that the ones presented by the book. David Hanson's C Interfaces and Implementations is a great complement to King's book.

Okay, thank you. It's obvious to me now I need to just spend the time and purchase some books and read up on the subject again. There's just been too much time I think that's passed since I last programmed. I remember taking a C programming class in college, advanced data structures, and there was another class. I don't remember if it was the advanced data structures class that dealt with stuff like linked lists and binary trees or if it was the third class. There was also an intro into C++ class I took but remember nothing from. Last time I had a job as a system programmer was back in 2005. That was over 10 years ago now and I guess I just need to relearn stuff. I've played with some small code since then, but nothing too complicated. I thought it'd all come back to me, like riding a bike, but unfortunately, the pointer stuff has been confusing me.

Thank you though for taking the time to help me. I appreciate it.

Originally Posted by migf1

...
The article says that when it was written, on x86 machines the sizeof an int was 4 bytes. It doesn't imply that this is always true.

Yeah, I didn't mean to imply that the article was implying that an int is always 4-bytes. I believe in the article, it actually tells you it might not be always 4-bytes. I remember when int on Windows was 2 bytes but in Linux, it was 4 bytes (or at least that's how I remember it). Let me try to rephrase my question.

If the size of a data type, like int, was 4-bytes on one system but 2-bytes on another, would that affect my code drastically? Would I have to do anything different when dealing with pointers? I try to use uint#_t, like uint8_t, when I need something that stores at least #-bits and when the size of the data type might matter. I don't know if this is a good practice or not though. I can't see where it could hurt anything, only help. But I've been out of the loop for some time now. I know it makes using printf and functions like printf a pain. I have to do stuff like,

Code:

    uint8_t my_age = 33;

    printf("Age: %" PRIu8 ".\n", my_age);

Perhaps there's a better way to do this and I just don't know the proper flag character?

Originally Posted by migf1

...
Yeap, they are exactly the same. In C, the 1st example is more idiomatic (the 2nd example is more common in C++).



The above code defines ptr_a as a double pointer to int, and ptr_b is defined a simple int. Try to avoid code like that. It becomes more clear if you use separate lines:

Code:

int **ptr_a;
int ptr_b;

Okay, I understand, and yeah, it is a lot clearer when you use separate lines. I just needed to make sure I understood. Thank you.