From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <01974d0bd36314a7c8172b6eca15effe@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] how to avoid a memset() optimization
From: "Russ Cox" <rsc@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Tue, 12 Nov 2002 19:31:13 -0500
Topicbox-Message-UUID: 1c4ced9e-eacb-11e9-9e20-41e7f4b1d025

> Plan9 has its own C compiler ) but seeing how gcc is making its
> way, it seems that declaring every buffer volatile ( as John the
> moderator has suggested ) wouldn't hurt either.

I disagree.  It hurts readability and clarity, all
to avoid a bug in gcc.  If I asked it to zero the
memory, then, damn it!, zero the memory.

The right fix is to avoid gcc.

After accepting the fact that gcc cannot be avoided,
cannot be fixed everywhere at once, and might not
ever be fixed anywhere at all, the right fix is to declare
a ``secure memset'' function:

	void*
	smemset(void *ap, int c, ulong n)
	{
		char *p;

		p = ap;
		while(n > 0) {
			*p++ = c;
			n--;
		}
		return ap;
	}

The only difference between this memset and the
standard portable libc memset is the name.
The point is that this only happens because gcc
is inlining the memset and then treating it as a
sequence of unused assignments.  Gcc ``knows'' too
much about memset.  If you call it something else,
that special knowledge goes away, as does the bug,
especially if smemset is in its own source file.

Russ