From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: "Douglas A. Gwyn" <DAGwyn@null.net>
Message-ID: <3DD35A06.7090802@null.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
References: <a7e3b9ec68921ac1a958447d0178eec7@vitanuova.com>, <20021113165620.GD82247@mero.morphisms.net>
Subject: Re: [9fans] how to avoid a memset() optimization
Date: Thu, 14 Nov 2002 10:21:56 +0000
Topicbox-Message-UUID: 1e850a42-eacb-11e9-9e20-41e7f4b1d025

William K. Josephson wrote:
> It gets worse: "you must use foo_uint32_t because we don't want
> to get burned if the size of the standard types change".  The
> amount of time I wasted yesterday all because people insist using
> poorly thought out additions to the language, header files, and
> libraries is not to be believed.  They mumble about "simplicity"
> and then insist on using the worst voodoo in C99 :-)

There is no foo_* in Standard C.
If you're referring to the <stdint.h> typedefs, those are
available so that programmers who *need* to be somewhat
precise about their integer widths have a standard way
to do so.  How much code have you had to port where it
was assumed that long was 32 bits, or 4 chars, or that
short was aliasable to an array of 2 chars?  We had the
dickens of a time getting such code fixed to work on
64-bit platforms.
If you're referring to such things as off_t needing to
be enlarged as a system evolves, applications don't need
to use anything other than off_t at the source level.
The only problem occurs at the binary interface level.
Vendors such as Sun who have had to deal with binary
compatibility in the face of types widening can explain
the problems and some of the (kludge) methods of
addressing them; there really isn't anything that could
have been done at the source level to prevent that problem.