🚀 go-pugleaf

In article <586@calma.UUCP> swang@calma.UUCP (Sin-Yaw Wang) writes:
>Say I have a big structure of close to 4 Kbytes.
>	
>	typedef  struct {
>		....
>		....
>	    } bigstruct;
>
>The chore is to initialize the entire structure to zero.  How do I do it?

The wrong way is to use bzero(), which fills a region with 0 bytes
and which exists only on Berkeley-based systems (System V/X3J11 use
memset()).  There are at least two problems with this:
	(1)  the struct padding may not be accessible on some architectures,
		so storing into it may cause a trap;
	(2)  0 bytes are not necessarily appropriate representations of the
		value zero for all data types, especially floating-point.

Try the following:

static bigstruct zero;	/* required to be initialized to 0s of proper types */

...

	bigstruct p;

	p = zero;	/* struct copy is optimized by compiler */

Suppose that, on your machine, ints are 4 bytes and must be aligned
on multiples of 4 bytes.  Chars, of course, are 1 byte.  Now declare:

	struct str {int i; char c;} arr[2], sca;
	char buf[32];

Now, in arr, each i member must go on a new 4-byte boundary, so there
is 3 bytes of padding after each c member.  So sizeof arr[0] is 8.

The most recent ANSI draft that I've examined specifies that if sizeof is
applied to a structure type, the result is the size of such a structure
including any trailing padding that would be necessary in an array of
such structures.  Therefore sizeof (struct str) is also 8 and, as far as
I know, sizeof sca is also 8.

However, the scalar struct sca is not required to have those 3 bytes
of padding.  This suggests that some compilers may place another
variable, say buf, at ((char *) &sca) + 5.  In this case a construct
such as the "bzero(&p, sizeof(p))" mentioned in Sin-Yaw Wang's article
The problem is that sca, the scalar struct, is NOT required to have
those 3 bytes of padding*.  Thus some compilers may decide to economize
on storage and place another variable, say buf, 5 bytes past the start
of sca.  And then, of course, something like the "bzero(&sca,sizeof sca);"
proposed in Sin-Yaw Wang's article (to which this is a followup) will
overwrite the first 3 elements of buf!

*K&R Appendix A does not speak of trailing padding at all; the most
 recent draft ANSI standard that I've examined does not speak of
 trailing padding in scalar structs.  I mentioned this to Larry Rosler,
 but I have not been able to check a later draft.  Of course, even if
 this is now covered, it doesn't affect current compilers.

ARE there any compilers out that don't always put trailing padding
on structs?  (Note: replies of the form "my compiler does put padding"
should not be posted unless there are a bunch of replies the other way!)

Mark Brader, utzoo!dciem!msb
#define	MSB(type)	(~(((unsigned type)-1)>>1))

In article <586@calma.UUCP> swang@calma.UUCP (Sin-Yaw Wang) writes:
>What is the most suitable (fast and portable among versions of Unix)
>way to do block initialization?
>

If you have an extra 4k of memory space I do the following:

----------
static struct bigstruct zerobigstruct;

main()
{
  struct bigstruct tobeused;

  tobeused = zerobigstruct;
  ...
}
----------

The above code obviously assumes that the compiler has structure
assignment which I think is a pretty safe assumption if you are
dealing with C compilers on Unix machines.

I realize that this is going to start the big debate about assignment
of structures being either field by field or a block move.  Lets not
get into that argument please.  My point here is if the compiler feels
a block move for the above code is correct then it can produce that.
If the compiler prefers field by field assignment, it can produce
that.  (I personally assume the above code produces a block move and
if that is not what I want, then I must explicitly tell the compiler
otherwise).
-- 
Perry Smith
ctvax ---\
megamax --- bobkat!pedz
pollux---/

Distribution:

I wrote:
>	struct str {int i; char c;} arr[2], sca;
>	char buf;
> The most recent ANSI draft that I've examined specifies that if sizeof is
> applied to a structure type, the result is the size of such a structure
> including any trailing padding that would be necessary in an array of
> such structures. ...

> However, the scalar struct sca is not required to have [the] padding.
> ... Thus some compilers may decide to economize
> on storage and place another variable, say buf, [where it would be] ...

According to mail from Larry Rosler, this has been fixed, and the current
draft reads:

# There may also be unnamed padding at the end of a structure,
# as necessary to achieve the appropriate alignment WERE the
# structure to be a member of an array.  [Emphasis added]

He has suggested that the definition of sizeof be simplified to remove
the "that would be necessary..." part, which is now redundant.

Mark Brader, utzoo!dciem!msb
	"You take the bottle out of the box, take the cotton out of the
	 bottle ... and if they'd just used the box and not used the bottle
	 ... look at this, all these pills would've fitted into the box and
	 they'd have had room for 3 times as much cotton!"   -- Andy Rooney

In article <1971@dciem.UUCP> msb@dciem.UUCP (Mark Brader) says that in
effect (&variable + sizeof(variable) > &nextvariable) is possible.
While I understand his argument and reasoning, I hope that this is not
true.  This would break many things it seems to me.  In particular,
varargs would be a very difficult thing to write since the "nextarg"
(or whatever it is called) would have to know the type of the next
argument in order to figure out the padding.  (I guess the compiler
could make an exception in the case of parameters passed on the
stack.)  It just seems like frequently code assumes that the
sizeof(variable) is exactly equal to the offset of that variable from
the next one.
-- 
Perry Smith
ctvax ---\
megamax --- bobkat!pedz
pollux---/

Perry Smith (pedz@bobkat.UUCP) writes:
> In article <1971@dciem.UUCP> msb@dciem.UUCP (Mark Brader) says that in
> effect (&variable + sizeof(variable) > &nextvariable) is possible.

This should, of course, be ((char *) &variable + sizeof(variable) >
(char *) &nextvariable).  I'm not saying that Perry doesn't know this,
since he said "in effect", but just reminding anyone who might be fooled.

> While I understand his argument and reasoning, I hope that this is not
> true.

Agreed.  And no one has yet come forth to say that it is true on their
machine, so maybe it is in fact never true.

Mark Brader

>>The chore is to initialize the entire structure to zero.  How do I do it?

In article <4510@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn
(VLD/VMB) <gwyn>) writes:
>The wrong way is to use bzero(), which fills a region with 0 bytes
>....

Structure assignment is fine in most cases, but suppose instead that
some hapless programmer is supposed to initialise a 40K-byte structure
using a small model compiler on an IBM PC?  There is no space for a
second copy of the structure.  Using bzero() here (assuming it exists,
or after writing it) is reasonable, given the compiler limitations.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

In article <3965@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes:
>>>The chore is to initialize the entire structure to zero.  How do I do it?
>
>Structure assignment is fine in most cases, but suppose instead that
>some hapless programmer is supposed to initialise a 40K-byte structure
>using a small model compiler on an IBM PC?  There is no space for a
>second copy of the structure.  Using bzero() here (assuming it exists,
>or after writing it) is reasonable, given the compiler limitations.

The obvious solution is to make assignment of zero to any structure a
defined operation guaranteed to get the appropriate bit patterns into
all the pointer elements.  Much cleaner than

	struct big_sucker { ... }	zero;	/* initialized to all zeros */
	main()
	{
		struct big_sucker	var;
		...
		var =	zero;	/* clear all elements of var */
		...
	}

would be
		var =	0;	/* (no comment needed) */

and much better for portability than using bzero().
I hope this gets provided for in ANSI C.

-- Tom Stockfisch, UCSD Chemistry

In article <414@sdchema.sdchem.UUCP> tps@sdchemf.UUCP (Tom Stockfisch) writes:
>The obvious solution is to make assignment of zero to any structure a
>defined operation guaranteed to get the appropriate bit patterns into
>all the pointer elements. ...
>
>		struct big_sucker	var;
>
>		var =	0;	/* (no comment needed) */

I dislike this: it is Yet Another Special Case.  I think the proper
obvious solution is to allow aggregate structure constants:

		var = { 0 };

The compiler can (*internally*) recognise this as a special constant
and not generate a static data object.  Aggregate structure constants
have other nice features:

	f(x)
		struct foo x;
	{
		...
	}

		f((struct foo) { 1, 27.3, "Hello world" });

They have problems as well; witness the ugly syntax used to attach
a type to an otherwise typeless aggregate.  As with the nil pointer
constant `0', aggregate constants can pick up their types from
expression context, but there are always cases where the context
is missing.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

[ ">>" and "" is me (Tom Stockfisch), and ">" is Chris Torek ]

>>The obvious solution is to make assignment of zero to any structure a
>>defined operation guaranteed to get the appropriate bit patterns into
>>all the pointer elements. ...
>>
>>		struct big_sucker	var;
>>
>>		var =	0;	/* (no comment needed) */

>I dislike this: it is Yet Another Special Case.

I see this as *eliminating* a special case, since we already have

	double		x =	0;
	int		i =	0;
	long		j =	0;
	char		*p =	0;
	char		c =	0;
	struct foo	*bar =	0;

and (as a special case)
	
	struct foo	elt =	0;

is disallowed.  All this extension does (I think) is add one more conversion
rule, specifying how "0" gets widened to a "struct foo".
So what would be the harm?

>...I think the proper
>obvious solution is to allow aggregate structure constants:
>
>		var = { 0 };

Of course I would like this feature to be added as well, especially when I
have to deal with complex numbers.  If I had to choose, I would take
	
	var =	{ 0 };

since it is more powerful.

-- Tom Stockfisch, UCSD Chemistry