[r2038] Weird randart thing

[Tiburon Silverflame]

Here's a good article on how HP's C compilers do it.

http://docs.hp.com/en/B3901-90003/ch05s05.html

There are gotchas in here, and definitely compiler dependencies. Unless there's a damn good reason, I'd also say, there should never be any unsigned int, short, or byte variables in the code, and there shouldn't be any signed/unsigned conversions.

[Pete Mack]

All well and good, but we haven't solved the original problem.

Magnate--what file and line number should I look at to find this problem?

-Pete

[zaimoni]

Here's a good article on how HP's C compilers do it.

http://docs.hp.com/en/B3901-90003/ch05s05.html

There are gotchas in here, and definitely compiler dependencies. Unless there's a damn good reason, I'd also say, there should never be any unsigned int, short, or byte variables in the code, and there shouldn't be any signed/unsigned conversions.

Sigh.
Welcome to h-basic.h:

#define N_ELEMENTS(a) (sizeof(a) / sizeof((a)[0]))

This macro is needed for accurate upper loop bounds on static arrays; result is an unsigned integer type per C90/C99 standards. Any for-loop counter variable compared to this has to be unsigned (preferably std::size_t, although unsigned int is often tenable) to avoid signed/unsigned conversion when comparing.

[PowerDiver]

Sigh.
Welcome to h-basic.h:

#define N_ELEMENTS(a) (sizeof(a) / sizeof((a)[0]))

This macro is needed for accurate upper loop bounds on static arrays; result is an unsigned integer type per C90/C99 standards. Any for-loop counter variable compared to this has to be unsigned (preferably std::size_t, although unsigned int is often tenable) to avoid signed/unsigned conversion when comparing.

Why would you care about conversion when comparing? Was this historically a problem? My imagination is lacking in figuring out what the issues could be.

If it is a problem, a gross solution might be to define the macro to cast to signed int. Besides being ridiculous, is there anything intrinsically broken about this gross idea?

The code I offer is unlikely to have size_t in it, and I bet there are other contributors equally unaware of when to use size_t.

[Magnate]

All well and good, but we haven't solved the original problem.

Magnate--what file and line number should I look at to find this problem?

-Pete

It's wiz-spoil.c line 513 ... but thanks for making me look it up, because I see now that I *did* use %u, copying ignorantly from the Min lev / Max lev / Gen chance which also used %u, instead of the weight which used %d.

Ah well, mystery solved. Thanks folks!

[Tiburon Silverflame]

Code:
#define N_ELEMENTS(a) (sizeof(a) / sizeof((a)[0]))
This macro is needed for accurate upper loop bounds...

When I see stuff like this, boy howdy does that say, it's time to get the *_@#$ OUT of a language that is so damn primitive that this is necessary.

[zaimoni]

Why would you care about conversion when comparing?

When I care that -1<0U is counterintuitively false. Which doesn't happen in those pervasive for-loops, counting up from 0 inclusive, in V.

Was this historically a problem? My imagination is lacking in figuring out what the issues could be.

Context: I am showing a presumed 4th-generation programming language addict that this superannuated, knee-jerk "safety fix" for C programs is a logic paradox.

[PowerDiver]

When I care that -1<0U is counterintuitively false. Which doesn't happen in those pervasive for-loops, counting up from 0 inclusive, in V.
Context: I am showing a presumed 4th-generation programming language addict that this superannuated, knee-jerk "safety fix" for C programs is a logic paradox.

Didn't there use to be some strange contexts where negative indices meant floor items in V? Maybe it is still in there.

It is quite possible to imagine using negative loop counters even when indexing into arrays. So much so that, a long time ago, I decided, for my own coding purposes, that loop counters should be signed rather than unsigned for extensibility even when it appears unsigned makes more sense. My only exception is looping over all possible packed bitflag combinations.

The only reason I'm beating this horse is that I always found the size_t stuff very strange. At least now I have an inkling why someone might want to do it. Thanks for that.

[zaimoni]

It is quite possible to imagine using negative loop counters even when indexing into arrays.

Yes. (My C memory manager reimplementation for Windows/GCC uses this to allow O(1) access to the exact size of a malloc-allocated memory block.) Note that ptrdiff_t, the result of subtracting two pointers, is a signed integer type -- and that strictly speaking operator [] is expecting one of its arguments to be a ptrdiff_t.

(Of course, std::size_t is a C++-ism; its C equivalent is size_t).

[zaimoni]

Didn't there use to be some strange contexts where negative indices meant floor items in V? Maybe it is still in there.

It's still there. But those indices are never actually used to dereference arrays as negative values.