So, in other words, it's Amateur Hour. All righty, then.
/backs toward door, reaches for doorknob, still smiling and nodding
For example, sort.Interface:
package sort
// A type, typically a collection, that satisfies sort.Interface can be
// sorted by the routines in this package. The methods require that the
// elements of the collection be enumerated by an integer index.
type Interface interface {
// Len is the number of elements in the collection.
Len() int
// Less returns whether the element with index i should sort
// before the element with index j.
Less(i, j int) bool
// Swap swaps the elements with indexes i and j.
Swap(i, j int)
}
ROFL. I challenge you to find documentation for the C language or any other language commonly used in production where they speculate that they might wake up one day and change sizeof(int) on an existing platform.
"Fantastically dumb," indeed.
You seem very ignorant, please learn and stop the FUD.
Yeah, that must be it.
As far as the documentation for the C langauge where they speculate that it's not defined, just given a minimum bound: here you go: Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign (C99 spec, section 5.2.4.2.1)
It also allows sign-magnitude integers (complement 1) in addition to complement 2 (C99 spec, section 6.2.6.2)
It also doesn't define the number of bits in a byte (C99 spec, section 3.6 p2)
No, C doesn't define sizeof(int). It is implementation defined. But you don't change it once you implement it in a given development environment... not if you want people to create and maintain production code with your tools. You don't speculate that one day you might want to change sizeof(int). It's just not something you do if you want to be taken seriously.
Is anyone in this thread over the age of 16?
If you write production C code that depends on anything other than the minimum sizes defined in limits.h, your code is buggy.