how to reset all structure fields to 0 or NULL

[Roman Mashak]

Hello, All!

I have a structure:

typedef struct cmd_line_s {
char *cl_action;
char *cl_args[10];
unsigned char cl_args_num;
void *cl_handler;
} cmd_line_t;

At initialization time I'm dooing cmd_line_t cli = { NULL, NULL, 0, NULL };

After dealing with 'cli' I'd like to reset fields values to { NULL, NULL, 0,
NULL } state again, what is the most correct and easy way?

Thank you!

With best regards, Roman Mashak. E-mail: (e-mail address removed)

 

[Eric Sosman]

Hello, All!

I have a structure:

typedef struct cmd_line_s {
char *cl_action;
char *cl_args[10];
unsigned char cl_args_num;
void *cl_handler;
} cmd_line_t;

At initialization time I'm dooing cmd_line_t cli = { NULL, NULL, 0, NULL };

After dealing with 'cli' I'd like to reset fields values to { NULL, NULL, 0,
NULL } state again, what is the most correct and easy way?

One way is to copy from an already-initialized instance:

const cmd_line_t empty_line = { NULL, NULL, 0, NULL };
cmd_line_t cli = { NULL, NULL, 0, NULL };
...
/* do things with cli */
...
cli = empty_line;
/* cli is now re-initialized */

C99 provides another way to do this, but it's not all that much
more convenient than the above in this sort of usage.

The initializer you've shown isn't quite complete, and may
cause some compilers to emit warning messages. You might try
rewriting it as

{ NULL, { NULL }, 0, NULL }

or even as

{ NULL,
{ NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL } ,
0,
NULL }

or perhaps just as

{ 0 }

 

[Walter Roberson]

I have a structure:

unsigned char cl_args_num;
void *cl_handler;

After dealing with 'cli' I'd like to reset fields values to { NULL, NULL, 0,
NULL } state again, what is the most correct and easy way?

Keep a null copy around and do a structure assignment. After, that
is, having freed whatever dynamic memory is appropriate.

 

[Roman Mashak]

Hello, Eric!
You wrote on Mon, 13 Jun 2005 22:45:55 -0400:

[skip]
ES> The initializer you've shown isn't quite complete, and may
ES> cause some compilers to emit warning messages. You might try
ES> rewriting it as

ES> { NULL, { NULL }, 0, NULL }

ES> or even as

ES> { NULL,
ES> { NULL, NULL, NULL, NULL, NULL,
ES> NULL, NULL, NULL, NULL, NULL } ,
ES> 0,
ES> NULL }

Thanks a lot!

With best regards, Roman Mashak. E-mail: (e-mail address removed)

 

[Jean-Claude Arbaut]

Le 14/06/2005 04:17, dans [email protected], « Roman Mashak »

Hello, All!

I have a structure:

typedef struct cmd_line_s {
char *cl_action;
char *cl_args[10];
unsigned char cl_args_num;
void *cl_handler;
} cmd_line_t;

At initialization time I'm dooing cmd_line_t cli = { NULL, NULL, 0, NULL };

After dealing with 'cli' I'd like to reset fields values to { NULL, NULL, 0,
NULL } state again, what is the most correct and easy way?

Thank you!

With best regards, Roman Mashak. E-mail: (e-mail address removed)

Most correct I don't know, but "memset" should work...

 

[pete]

Le 14/06/2005 04:17, dans [email protected], « Roman Mashak »

Hello, All!

I have a structure:

typedef struct cmd_line_s {
char *cl_action;
char *cl_args[10];
unsigned char cl_args_num;
void *cl_handler;
} cmd_line_t;

At initialization time I'm dooing cmd_line_t
cli = { NULL, NULL, 0, NULL };

After dealing with 'cli' I'd like to reset
fields values to { NULL, NULL, 0,
NULL } state again, what is the most correct and easy way?

Thank you!

With best regards, Roman Mashak. E-mail: (e-mail address removed)

Most correct I don't know, but "memset" should work...

memset(&pointers, 0, sizeof pointers)
is the wrong way to set pointers to NULL.

 

[Jean-Claude Arbaut]

memset(&pointers, 0, sizeof pointers)
is the wrong way to set pointers to NULL.

Oh, excuse me, I thought NULL was null

 

[Dik T. Winter]

>
>
> Oh, excuse me, I thought NULL was null

The null pointer does not have necessarily all bits 0 (as a floating
point 0.0 has not necessarily all bits 0).

 

[Jean-Claude Arbaut]

Le 14/06/2005 14:21, dans (e-mail address removed), « Dik T. Winter »

The null pointer does not have necessarily all bits 0 (as a floating
point 0.0 has not necessarily all bits 0).

Ok. I don't know all architectures, so assigning 0 may be non portable,
although on some OS (MacOSX for example), NULL is defigned as 0:

#define NULL __DARWIN_NULL
#define __DARWIN_NULL ((void *)0)

And the example of floating point 0.0 is irrelevant, +0.0 and -0.0
are two distinct values.

Just one question unrelated with NULLs, is it allowed to write "sizeof int",
or only "sizeof(int)" ? I wonder if GCC correctly follows the Standard...
I get:

test.c: In function 'main':
test.c:5: error: parse error before 'int'

 

[Dik T. Winter]

> Le 14/06/2005 14:21, dans (e-mail address removed), « Dik T. Winter »

>
> Ok. I don't know all architectures, so assigning 0 may be non portable,
> although on some OS (MacOSX for example), NULL is defigned as 0:
>
> #define NULL __DARWIN_NULL
> #define __DARWIN_NULL ((void *)0)

Perfectly conforming to the standard. And if that is done on a machine
where the 0 pointer has not all bits 0, the compiler has to ensure that
the proper bit pattern is used for a null pointer, although the source
may contain the constant 0. 0 in a pointer context does *not* mean a
pointer with all bits 0, it means a null pointer.

> And the example of floating point 0.0 is irrelevant, +0.0 and -0.0
> are two distinct values.

Not in C and not on all machines. But it is relevant. I know one
machine where all bits 0 is a non-normalized 0.0. So if a has that
value, and b is 3.5, a + b will be 3.0.

> Just one question unrelated with NULLs, is it allowed to write "sizeof int",
> or only "sizeof(int)" ? I wonder if GCC correctly follows the Standard...
> I get:
>
> test.c: In function 'main':
> test.c:5: error: parse error before 'int'

Only sizeof(int), see the standard. The parenthesis are required when sizeof
is applied to a type.

 

[Jean-Claude Arbaut]

Le 14/06/2005 15:54, dans (e-mail address removed), « Dik T. Winter »

Le 14/06/2005 14:21, dans (e-mail address removed), « Dik T. Winter »


Perfectly conforming to the standard. And if that is done on a machine
where the 0 pointer has not all bits 0, the compiler has to ensure that
the proper bit pattern is used for a null pointer, although the source
may contain the constant 0. 0 in a pointer context does *not* mean a
pointer with all bits 0, it means a null pointer.

You're right. But on MacOSX/PowerPC, the NULL pointer *is* 0. Not compiler
trick, you can check the assembly output. And the "segment zero" is
here to crash if the NULL pointer is dereferenced.

Not in C and not on all machines. But it is relevant. I know one
machine where all bits 0 is a non-normalized 0.0. So if a has that
value, and b is 3.5, a + b will be 3.0.

Sorry, I had IEEE 754 in mind. 0.0 and -0.0 are distinct (juste compute
1/x to check this), but 0.0 == -0.0. I'm pretty sure it's perfect IEEE
behaviour. But you're right: one must not use memset to initialize
a zero fp vector... funny.

Only sizeof(int), see the standard. The parenthesis are required when sizeof
is applied to a type.

Thanks.

 

[Clark S. Cox III]

Le 14/06/2005 14:21, dans (e-mail address removed), « Dik T. Winter »


Ok. I don't know all architectures, so assigning 0 may be non portable,
although on some OS (MacOSX for example),

Assigning zero to a pointer variable is *always* OK, and will always
result in a NULL pointer. But that doesn't mean that the actual, in
memory representation of that NULL pointer is "all-bits zero"

And the example of floating point 0.0 is irrelevant, +0.0 and -0.0
are two distinct values.

Not always, and the example is quite relevant.

Just one question unrelated with NULLs, is it allowed to write "sizeof int",
or only "sizeof(int)" ?

No, when applied to a type, only sizeof(type) is allowed.

 

[S.Tobias]

[snip all]

Could you please fix something in your reader, so that it doesn't
insert a space between "Re" and ":" in the subject? I think other
readers don't recognize "Re :" as "regarding" (or "reply"?) prefix
and add their own "Re:"; then probably your reader changes it to "Re :"
again, and the "game of life" restarts. In my reader in threads
menu I'll soon be seeing only "Re : Re : Re : Re : Re : Re : ...".

 

[Jean-Claude Arbaut]

Le 14/06/2005 17:11, dans (e-mail address removed), « S.Tobias »

[snip all]

Could you please fix something in your reader, so that it doesn't
insert a space between "Re" and ":" in the subject? I think other
readers don't recognize "Re :" as "regarding" (or "reply"?) prefix
and add their own "Re:"; then probably your reader changes it to "Re :"
again, and the "game of life" restarts. In my reader in threads
menu I'll soon be seeing only "Re : Re : Re : Re : Re : Re : ...".

Sorry, I didn't see... The origin is Microsoft Entourage and its
interpretation of french language rule: it puts a space before a
colon, by default. I'll probably switch my news reader soon

 

[CBFalconer]

typedef struct cmd_line_s {
char *cl_action;
char *cl_args[10];
unsigned char cl_args_num;
void *cl_handler;
} cmd_line_t;

At initialization time I'm dooing
cmd_line_t cli = { NULL, NULL, 0, NULL };

After dealing with 'cli' I'd like to reset fields values to
{ NULL, NULL, 0, NULL } state again, what is the most correct
and easy way?

Most correct I don't know, but "memset" should work...

Definitely incorrect. Those may not be NULLs. Suggested means:

....
/* Very suitable use for a global */
const cmd_line_t clempty = {NULL, NULL, 0, NULL);
....
int main(...)
{
....
cmd_line_t cli = clempty;
....
do {
/* fool with cli */
cli = clempty; /* rezero it */
} while (something);
....
}

 

[Walter Roberson]

Sorry, I had IEEE 754 in mind. 0.0 and -0.0 are distinct (juste compute
1/x to check this), but 0.0 == -0.0. I'm pretty sure it's perfect IEEE
behaviour. But you're right: one must not use memset to initialize
a zero fp vector... funny.

I do not recall the author at the moment, but a few weeks ago
someone posted here indicating that the standard special-cases
all-0 bits as being a valid representation of floating point 0
(but not necessarily the one that will be stored if a 0 is computed.)

But on MacOSX/PowerPC, the NULL pointer *is* 0.

Irrelevant when it comes to writing standard code. What is important
is that if one writes binary 0's to an object pointer cast to char*
or void* [e.g., memset()], and then reinterprets a fragment of
that zero'd object as a pointer, then that pointer will not necessarily
be a NULL pointer.

The guarantees about the NULL pointer comparing equal to 0, or that
assigning 0 shall result in the NULL pointer, are not guarantees that a
bit pattern of all-zeroes will also be a NULL pointer: the guarantees
only hold in the cases where the compiler is able to determine that
numeric 0 is being assigned... and the compiler is allowed to
"intercept" those assignments and comparisions and put in special
handling.

There are, for example, systems on which low memory is valid
storage locations (e.g., trap vectors or I/O words or bitmapped
graphics), and in which the all-0-bits pointer is a valid
address; for such a system, the NULL pointer might be internally
represented as (say) all-1-bits or as any pointer that has the
MSB set, or any of a number of other possibilities.

 

[Lawrence Kirby]

I do not recall the author at the moment, but a few weeks ago
someone posted here indicating that the standard special-cases
all-0 bits as being a valid representation of floating point 0
(but not necessarily the one that will be stored if a 0 is computed.)

I believe that is now true for integer types, but not floating point types.

Lawrence

 

[Richard Bos]

Le 14/06/2005 17:11, dans (e-mail address removed), « S.Tobias »

[snip all]

Could you please fix something in your reader, so that it doesn't
insert a space between "Re" and ":" in the subject? I think other
readers don't recognize "Re :" as "regarding" (or "reply"?) prefix
and add their own "Re:"; then probably your reader changes it to "Re :"
again, and the "game of life" restarts. In my reader in threads
menu I'll soon be seeing only "Re : Re : Re : Re : Re : Re : ...".

Sorry, I didn't see... The origin is Microsoft Entourage and its
interpretation of french language rule:

Actually, the origin is M$ <no matter which Usenet program> and its use
of a French language rule at all. The reply mark should be, literally,
"Re: "; pretending that there is such a thing as "French Usenet rules"
and translating "Re: " into anything else, no matter what, is a sign of
great, incurable, and probably intentional lositude. I suppose we
shouldn't complain because it's a mercy they haven't tried to translate
the actual Usenet _headers_, but it's still moronically arrogant to do a
thing like this.
This rant directed at Redmond, not at you.

Richard

 

[Christian Bau]

Actually, the origin is M$ <no matter which Usenet program> and its use
of a French language rule at all. The reply mark should be, literally,
"Re: "; pretending that there is such a thing as "French Usenet rules"
and translating "Re: " into anything else, no matter what, is a sign of
great, incurable, and probably intentional lositude. I suppose we
shouldn't complain because it's a mercy they haven't tried to translate
the actual Usenet _headers_, but it's still moronically arrogant to do a
thing like this.
This rant directed at Redmond, not at you.

A bug that has cost some european Microsoft customers tons of money:

Create an Excel spreadsheet. Enter numbers. Set cell formatting to
"Currency". The numbers will be displayed in your local currency.

email that spreadsheet to someone in a different country. They open it,
the numbers come out in _their_ currency. Say you write an offer to
build some stuff for $100,000 which is a decent price. Your customer in
the UK reads £100,000 which is absurdly expensive. You lose a contract.

 

[Richard Bos]

A bug that has cost some european Microsoft customers tons of money:

Create an Excel spreadsheet. Enter numbers. Set cell formatting to
"Currency". The numbers will be displayed in your local currency.

email that spreadsheet to someone in a different country. They open it,
the numbers come out in _their_ currency. Say you write an offer to
build some stuff for $100,000 which is a decent price. Your customer in
the UK reads £100,000 which is absurdly expensive. You lose a contract.

Ow... that's even worse than the one where they'd translate not just the
static text in Excel, but even the identifiers of their macro language.
Imagine that, to compile an English C program in the Netherlands, you'd
have to translate all fread() calls to blees(), and all size_t's to
grootte_t... Well, that's exactly what was necessary with that version
of Excel.

Richard