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: mr*@tusur.ru

[Eric Sosman]

Roman Mashak wrote:

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 }

--
Eric Sosman
es*****@acm-dot-org.invalid

[Walter Roberson]

In article <d8**********@relay.tomsk.ru>, Roman Mashak <mr*@tusur.ru> wrote:

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.

--
Entropy is the logarithm of probability -- Boltzmann

[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: mr*@tusur.ru

[Jean-Claude Arbaut]

Le 14/06/2005 04:17, dans d8**********@relay.tomsk.ru, «*Roman Mashak*»
<mr*@tusur.ru> a écrit*:

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: mr*@tusur.ru

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

[pete]

Jean-Claude Arbaut wrote:

Le 14/06/2005 04:17, dans d8**********@relay.tomsk.ru, « Roman Mashak »
<mr*@tusur.ru> a écrit :

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: mr*@tusur.ru

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

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

--
pete

[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]

In article <BE******************************@laposte.net> Jean-Claude Arbaut <je****************@laposte.net> writes:

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

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).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Jean-Claude Arbaut]

Le 14/06/2005 14:21, dans II********@cwi.nl, «*Dik T. Winter*»
<Di********@cwi.nl> a écrit*:

In article <BE******************************@laposte.net> Jean-Claude Arbaut
<je****************@laposte.net> writes:

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

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).

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]

In article <BE******************************@laposte.net> Jean-Claude Arbaut <je****************@laposte.net> writes:

Le 14/06/2005 14:21, dans II********@cwi.nl, «*Dik T. Winter*»
<Di********@cwi.nl> a écrit*:

In article <BED491DD.3131%je****************@laposte.net> Jean-Claude Arbaut
<je****************@laposte.net> writes: ....

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).

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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Jean-Claude Arbaut]

Le 14/06/2005 15:54, dans II********@cwi.nl, «*Dik T. Winter*»
<Di********@cwi.nl> a écrit*:

In article <BE******************************@laposte.net> Jean-Claude Arbaut
<je****************@laposte.net> writes:

Le 14/06/2005 14:21, dans II********@cwi.nl, «*Dik T. Winter*»
<Di********@cwi.nl> a écrit*:

In article <BED491DD.3131%je****************@laposte.net> Jean-Claude Arbaut
<je****************@laposte.net> writes: ...
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).

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.

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.

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.

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.

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.

Thanks.

[Clark S. Cox III]

On 2005-06-14 08:55:41 -0400, Jean-Claude Arbaut
<je****************@laposte.net> said:

Le 14/06/2005 14:21, dans II********@cwi.nl, «*Dik T. Winter*»
<Di********@cwi.nl> a écrit*:

In article <BED491DD.3131%je****************@laposte.net> Jean-Claude Arbaut
<je****************@laposte.net> writes:

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

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).

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.

--
Clark S. Cox, III
cl*******@gmail.com

[S.Tobias]

Jean-Claude Arbaut <je****************@laposte.net> wrote:
[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 : ...".

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Jean-Claude Arbaut]

Le 14/06/2005 17:11, dans 3h************@individual.net, «*S.Tobias*»
<si***@FamOuS.BedBuG.pAlS.INVALID> a écrit*:

Jean-Claude Arbaut <je****************@laposte.net> wrote:
[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]

Jean-Claude Arbaut wrote:

« Roman Mashak » <mr*@tusur.ru> a écrit :

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);
....
}

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Walter Roberson]

In article <BE******************************@laposte.net>,
Jean-Claude Arbaut <je****************@laposte.net> wrote:

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.
--
"I want to make sure [a user] can't get through ... an online
experience without hitting a Microsoft ad"
-- Steve Ballmer [Microsoft Chief Executive]

[Lawrence Kirby]

On Tue, 14 Jun 2005 16:17:00 +0000, Walter Roberson wrote:

In article <BE******************************@laposte.net>,
Jean-Claude Arbaut <je****************@laposte.net> wrote:

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.)

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

Lawrence

[Richard Bos]

Jean-Claude Arbaut <je****************@laposte.net> wrote:

Le 14/06/2005 17:11, dans 3h************@individual.net, «*S.Tobias*»
<si***@FamOuS.BedBuG.pAlS.INVALID> a écrit*:

Jean-Claude Arbaut <je****************@laposte.net> wrote:
[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]

In article <42****************@news.xs4all.nl>,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

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]

Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:

In article <42****************@news.xs4all.nl>,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

Actually, the origin is M$ <no matter which Usenet program> and its use
of a French language rule at all.

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

[Jean-Claude Arbaut]

Le 15/06/2005 10:35, dans 42****************@news.xs4all.nl, «*Richard Bos*»
<rl*@hoekstra-uitgeverij.nl> a écrit*:

Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:

In article <42****************@news.xs4all.nl>,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

Actually, the origin is M$ <no matter which Usenet program> and its use
of a French language rule at all.

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.

I know, I had a french Excel once... Awful, even for a french.
Everybody knows IF, FOR, etc... Why use anything else ?

[Mark McIntyre]

On Wed, 15 Jun 2005 06:19:19 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

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: ";

At least they still spell it "Re". Lotus Notes spells it arr e-acute-
eff space colon. Gah
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Wed, 15 Jun 2005 08:08:42 +0100, in comp.lang.c , Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

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.
I don't recall seeing this, and I worked for a french bank for 10
years, so we frequently exchanged spreadsheets from both English and
French excel.
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.

actually it would come out as £100.000 which is absurdly cheap, since
the comma in french excel means dot in english...

Ah, l'internationalization, es ist zehr annoying, niet?
:-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Dik T. Winter]

In article <ht********************************@4ax.com> Mark McIntyre <ma**********@spamcop.net> writes:

On Wed, 15 Jun 2005 06:19:19 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

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: ";

At least they still spell it "Re". Lotus Notes spells it arr e-acute-
eff space colon. Gah

Yes, there is much confusion about it. It is from Latin and does not refer
to any English word. "In re".
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Richard Bos]

Mark McIntyre <ma**********@spamcop.net> wrote:

On Wed, 15 Jun 2005 06:19:19 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

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: ";

At least they still spell it "Re".

Or, in some versions, "Sv:". There is no limit to the idiocy of this
company.

Richard