How to set an array slot to NULL

I guess this is a really basic question and I've researched but couldn't find my answer.

The thing I want to set all the slots of an array of stucts to NULL.

If I do this

Code:

---

shMem->array[i] = NULL;

---

I get

Code:

---

error: incompatible types in assignment

---

So how can I set the slots to NULL so I can know they aren't used?

Thanks in advance.

And what type are the elements of array ?

NULL in C is a pointer with the value 0 (or something corresponding to that in some implementations)...

--
Mats

It's an array of tasks in a struct for shared memory

Code:

---

typedef struct _task{
        char path [MAX_PATH_LEN];
        char thread_id[MAX_PATH_LEN];
        char op;
        struct _task* ptr;
}task;

typedef struct _sharedMem{
        task array [50];
        int lastIn;
        int numTasks;
        sem_t mutex;
}sharedMem;

---

I see so as it's a pointer you can really equal it to an array slot.

So the alternative would be to set the struct in that slot so that I know that it's not being use? I never have a problem just calling an attribute of an object in an array?

Ehm, are you actually storing this in shared memory? If so,

Code:

---

        struct _task* ptr;

---

is a dangerous construct, as if we assume it points within the shared memory, you can not be guaranteed that the shared memory is at the same location in different processes - the OS may have used that virtual address for something else by the time you open the shared memory. Use an offset from the start of your shared memory instead of a pointer, the make it a pointer by adding it to the shared memory base address when you need to get to it.

You obviously can't use NULL to assign to a struct, so yes, you will need to put some value somewhere that indicates "not in use" within your task struct.

Also, using names that start with _ is a bad idea in general, as such names are reserved for the compiler/C library implementors.

--
Mats

The easy answer is:

Code:

---

memset( array, '\0', sizeof( array ) );

---

But that may not always be the right way to do it (i.e. your structs might have memory that needs to be free'd first).

Quote:

---

Originally Posted by kotoko

It's an array of tasks in a struct for shared memory

Code:

---

typedef struct _task{
        char path [MAX_PATH_LEN];
        char thread_id[MAX_PATH_LEN];
        char op;
        struct _task* ptr;
}task;

typedef struct _sharedMem{
        task array [50];
        int lastIn;
        int numTasks;
        sem_t mutex;
}sharedMem;

---

I see so as it's a pointer you can really equal it to an array slot.

So the alternative would be to set the struct in that slot so that I know that it's not being use? I never have a problem just calling an attribute of an object in an array?

---

Look at the memset() call to initialize the array of task structs or a particular element thereof to NULL.

Quote:

---

Originally Posted by itCbitC

Look at the memset() call to initialize the array of task structs or a particular element thereof to NULL.

---

Well, you can set all elements to zero - if some implementation of compiler decides that NULL is actually internally represented by something other than zero, you may be in trouble.

Of course, as discussed above, you should not have pointers in shared memory, so storing NULL anywhere within a shared memory block is unlikely to be the RIGHT thing to do.

--
Mats

Thanks for the heads up with the pointer problem, I'm adapting from a threads program so I didn't notice that yet. I guess I'll just substitute that with the index of the array, that might be simpler.

Quote:

---

you will need to put some value somewhere that indicates "not in use" within your task struct.

---

My problem with this is that I'm not sure what happens when you do a shMem->array[i].path to something that hasn't been used. but I guess it's fine and I'm, being silly.

Quote:

---

Also, using names that start with _ is a bad idea in general, as such names are reserved for the compiler/C library implementors.

---

I didn't know about that, thanks.

Quote:

---

Originally Posted by matsp

Well, you can set all elements to zero - if some implementation of compiler decides that NULL is actually internally represented by something other than zero, you may be in trouble.

---

IMHO that would be decided internally by the machine's native character set ie ASCII or EBCDIC instead of by the compiler.

Quote:

---

Originally Posted by itCbitC

IMHO that would be decided internally by the machine's native character set ie ASCII or EBCDIC instead of by the compiler.

---

Ehm, that is a different NULL - NULL here, in C, is [usually]

Code:

---

#define NULL ((void *) 0)

---

So whilst that may well cause the memory to be filled with the zero value, it is not guaranteed that

Code:

---

int *ptr = NULL;

---

actually stores a zero value in the memory occupied by the variable p - the compiler & C library MAY decide that NULL is actually -1 - it should still behave AS IF NULL is zero if you do "if (p == 0) ... ", but the actual machine code would compare p with -1. [Just as an example, of course].

Admittedly, I'm picking holes by pedantery, but if I'm sure someone else would shove the same argument down my throat if I made such a suggestion.

--
Mats

Quote:

---

Originally Posted by matsp

Ehm, that is a different NULL - NULL here, in C, is [usually]

Code:

---

#define NULL ((void *) 0)

---

---

Correct as the NULL symbol can be redefined elsewhere thereby taking precedence over its definition in the C library include files.

Quote:

---

Originally Posted by matsp

So whilst that may well cause the memory to be filled with the zero value, it is not guaranteed that

Code:

---

int *ptr = NULL;

---

actually stores a zero value in the memory occupied by the variable p - the compiler & C library MAY decide that NULL is actually -1 - it should still behave AS IF NULL is zero if you do "if (p == 0) ... ", but the actual machine code would compare p with -1. [Just as an example, of course].

---

I concur

Quote:

---

Originally Posted by matsp

Admittedly, I'm picking holes by pedantery, but if I'm sure someone else would shove the same argument down my throat if I made such a suggestion.

--
Mats

---

#define NULL ((void *)0L) now that's pedantic :D

Quote:

---

Originally Posted by itCbitC

#define NULL ((void *)0L) now that's pedantic

---

How is that pedantic?

Quote:

---

Originally Posted by laserlight

How is that pedantic?

---

and why not? go figure :D

Quote:

---

Originally Posted by itCbitC

and why not?

---

Because section 6.3.2.3 paragraph 3 of the 1999 edition of the C Standard states:

Quote:

---

An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.

---

with the note:

Quote:

---

The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant

---

For a long int, the value 0 can be expressed by the constant 0L, but long int is not a pointer type anyway. My point is that to be pedantic, the standard allows both (void*)0 and (void*)0L, so suggesting that (void*)0L is pedantic in the face of the previous expression is... not being pedantic.

Quote:

---

Originally Posted by laserlight

Because section 6.3.2.3 paragraph 3 of the 1999 edition of the C Standard states:

with the note:

For a long int, the value 0 can be expressed by the constant 0L, but long int is not a pointer type anyway. My point is that to be pedantic, the standard allows both (void*)0 and (void*)0L, so suggesting that (void*)0L is pedantic in the face of the previous expression is... not being pedantic.

---

agree that long int 0L by itself is not a pointer and by the same argument neither is int 0L unless cast.
imo only difference is the precision and pedantic in this context refers purely to the degree of precision.

Quote:

---

Originally Posted by itCbitC

imo only difference is the precision and pedantic in this context refers puely to the degree of precision.

---

As stated in the standard, NULL as defined in <stddef.h> is implementation defined. If the implementation defines NULL as ((void*)0), then NULL is ((void*)0). There is nothing generally "more" pedantic about defining NULL as ((void*)0L).

By the way, do you read your private messages? I was hoping to have this discussion with you via PM since it adds little to the discussion, though kotoko might be able to benefit.

Quote:

---

Originally Posted by laserlight

As stated in the standard, NULL as defined in <stddef.h> is implementation defined. If the implementation defines NULL as ((void*)0), then NULL is ((void*)0). There is nothing generally "more" pedantic about defining NULL as ((void*)0L).

By the way, do you read your private messages? I was hoping to have this discussion with you via PM since it adds little to the discussion, though kotoko might be able to benefit.

---

agree for the benefit of the OP we should take it offline ;)
btw i replied to your PM so whenever you get a chance...

Quote:

---

Originally Posted by itCbitC

agree for the benefit of the OP we should take it offline ;)
btw i replied to your PM so whenever you get a chance...

---

Quote:

---

Originally Posted by Microsoft Visual Studio

Code:

---

#ifndef NULL
#ifdef  __cplusplus
#define NULL    0
#else
#define NULL    ((void *)0)
#endif
#endif

---

---

No L there..

--
Mats

Code:

---

#if defined(_ANSI_NULL_POINTER) && defined(__STDC__)
  #define NULL ((void *)0L)
#else
  #define NULL 0L
#endif

---

Quote:

---

Originally Posted by itCbitC

Code:

---

#if defined(_ANSI_NULL_POINTER) && defined(__STDC__)
  #define NULL ((void *)0L)
#else
  #define NULL 0L
#endif

---

---

Yes, I was just proving the point, just like you are - where is that from?

--
Mats

Quote:

---

Originally Posted by matsp

Yes, I was just proving the point, just like you are - where is that from?

--
Mats

---

that code snippet has been taken from an IRIX w/s.