[rescue] Help with SunFire V240 Server

[Carl R. Friend]

    On Sun, 7 Apr 2013, Peter Corlett wrote:

> It's not always obvious from API documentation whether a field is signed or
> unsigned, and signed values will often get shoved into an int, whether by
> accident, laziness, or a feature/bug in one's language.

    On item (1) above, there is no excuse for lazy documentation; if
something is worth writing, it's worth writing *correctly*, and if
a value is *unsigned* (and that keyword exists for a reason) it
should be so documented, or be patently obvious (e.g. "WTF is
'cylinder negative one'?").

    On item (2) above, that's what compiler warnings and good coding
standards are all about.  Oh, wait; "lint" is a fond memory from the
past and nobody pays any attentions to warnings any more because all
the world's a GNU.

> So it's defensive design to treat unsigned values with a MSB of 1
> as an error.

    ... which completely removes the usefulness of the data type.

    And to think we call this "progress".

> You'll see this pattern all over the place. For example, userspace
> pointers in x86_64 operating systems are always positive when cast
> to int64_t.

    And since when is the x86/* any sort of paragon of virtue?

> Java doesn't allow unsigned integers at all to avoid just this
> problem.

    Interpreted and B&D languages need not apply [for employment].
This is the real world, not academia.  Try telling somebody doing
embedded work that they should give up unsigned data-types.

    The point is that the data-type has *very* useful real-world
applications.  Removing it from the lexicon -- or worse, bowlderdising
it -- is a huge dis-service to computing.

    Cheers!

+------------------------------------------------+---------------------+
| Carl Richard Friend (UNIX Sysadmin)            | West Boylston       |
| Minicomputer Collector / Enthusiast            | Massachusetts, USA  |
| mailto:crfriend at rcn.com                        +---------------------+
| http://users.rcn.com/crfriend/museum           | ICBM: 42:22N 71:47W |
+------------------------------------------------+---------------------+