Re: [ANN] Lua 5.3.0 (work1) now available

[William Ahern <william@...>]

On Mon, Jul 08, 2013 at 10:15:04AM -0300, Roberto Ierusalimschy wrote:
> > > That may not do what is expected, because it involves 
> > > implementation-defined behavior:
> > > 
> > > 3.2.1.2 Signed and unsigned integers [...]  When an integer is
> > > demoted to a signed integer with smaller size, or an unsigned
> > > integer is converted to its corresponding signed integer, if the
> > > value cannot be represented the result is implementation-defined.
> > 
> > If I remember right, you can work around this with a memcpy() from the
> > unsigned variable to the signed variable.
> 
> Before trying to solve a problem, let us be sure there is a
> problem. Have anyone ever used a C implementation where the conversion
> from unsigned int to int did not have the "expected" behavior (keep the
> bits unchanged)?
> 

I can't say I have, but FWIW Unisys still sells signed-magnitude mainframe
environments with a C90 compiler:

	Signed and Unsigned Type Comparisons 

	The comparison of negative numbers with unsigned types may behave
	differently on A Series systems than on other platforms. Platforms
	that store arithmetic values in one's or two's complement form store
	the sign when assigning to an unsigned type. On A Series systems,
	the sign is not stored when assigning to an unsigned type. On A
	Series systems, comparing a negative value with the value in an
	unsigned type will never be true unless the CHAR2 or UNSIGNED
	subordinate options of the PORT compiler control option are used to
	emulate two's complement arithmetic on unsigned types. Another
	workaround is to change negative literals to their one's complement
	values (for example, -1 becomes 0xFF)

	-- http://public.support.unisys.com/aseries/docs/clearpath-mcp-14.0/pdf/86002268-205.pdf