Re: Another hyperspace bug found --> random and Neural Net

On Thu, Jun 19, 2008 at 2:31 PM, Bill Yerazunis <[email protected]> wrote:
>
> Yep.  Here's another worm (unsightly and annoying)...
>
> Why is it that x86 GCC doesn't believe that "unsigned long"
> and "uint32_t" are the same type underneath?
>
> Specifically, when doing an fprintf, I get annoying warnings
> that there's a type mismatch.
>
> Is this me?  Is there a flag that says "Yo!  Be smart about
> what a type is!" or some such like that?
>
>     - Crash

Dear Cpt. Crash,

GCC is correct.

uint32_t and unsigned long are not the same.
See the ISO C99 standard: uint32_t guarantees bit size, the C89
integer types do not. GCC warns you about that.

So there's not a 'Yo, smarten up' flag, /unless/ it's that one I am so
desperately waving overhere across the Atlantic for a while already.
;-) (Seen me hopping up and down on Scheveningen beach last week?
Probably not, horizon is in the way, even if we hadn't air itself to
degrade visibility even at the best of times.)

See also our, now probably antiquated, discussion over 'int' and
'long'. Or do I mistake my monologue for 'discussion' again? :-))
Alas, in another age I might have become a missionary and be roasted
crispy by the aborginals the morning after my arrival. I'm very lucky.


Yours sincerely,

Ger



Bottom line: my tip of the day:

(1) you are accessing persistent storage (either through mmap()ed
memory or file I/O or otherwise): use C99 [u]int[8|16|32]_t types to
ensure bit width across platforms. Let the nutters like me care about
pore-C99 systems by using a GNU autoconf-based system.

I may lean towards 'char' as an acceptable alternative for 'int8_t' as
the days of 9/36-bit platforms have been numbered (though they still
exist, yes sir). Major representative of that group: PDP-[7..11]. Viva
el Digital. Imagine porting C code to those boxes: /definitely/ not
for n00bs <evil laugh>

(2) when you perform calculations: use 'int' and 'int' only unless you
have ascended to the next astral plane, i.e. you know what you are
doing at a rather detailed level and the effects of your work on
multiple platforms. Alternatively, use double. Or 'float' if you must,
but be ready for a few unexpected surprises then. (quite a bit of 3D
render software uses 'float' for improved speed, for example. CRM114
is NOT an example for float IMHO as we perform very few floating point
operations, compared to the 3D/video-render folks. And they have to
watch their six continuously, so 'double' is a safe haven if you want
to mind the algorithms and not the platform idiocies.





------<rant>--------------------------------

GCC is smart enough to know about this: it warns you, VERY correctly,
because the folks who designed GCC spend quite some time on issues
like these, and they decided to warn you your code MAY compile on your
box but MAY contain artifacts which render it nonportable in some
particular way.

Anyway, when you or anyone wonders why int/long/int32_t again: here's
a little pop quiz for y'all: why did the GNU folks develop those
autoconf tools and configure scripts? Because they love collecting
system idiosyncracies like 'normal' folks might collect stamps or
political campaign buttons? My answer? No. They did it because they
wanted to increase their market share. And you don't get to improve
your market penetration by requiring every user to buy and use a
predefined system (I know enough companies who do not allow Linux
inside their corporate firewalls) but by lowering the decision
threshold through taking those idiosyncracies into account. If you
ever feel like it, take one of the pinnacles of portable code, the GNU
GCC compiler source code itself, and have a look at the configure
script and platform dependent configuration bits and pieces. Don't be
amazed and leave. Try to learn from them.

Writing [portable] software is a skill. Demand for that skill is way
larger than the availability of that skill. So quacks galore. Hence,
don't take me for my word. Have a look at the GNU code. Start with
their 'hello world' program; it sounds like a joke, but there's
several lessons worth in there too. Take a dive and download and look
at the GCC source code and configuration setup. Those folks are among
the few who have provable successful ports to a multitude of systems.
Look at their stuff, keep those 1+2 tip of the day items handy and
validate them against the GNU code out there. Compare, learn and
decide how far you want to go in this game. (My goal is: portable to
any machine with an 8-bit byte, 32-bit or higher native machine word
and any compiler which supports the non-standard 'long long'. That's
'all the way' within the boundaries set by the CRM114 algorithms and
basic implementation.)




How about the CRM114 case in this regard (int vs. long vs. int32_t)?

Since CRM114 also ASSUMES your compiler out there knows about the
non-standard 'long long' you may be in for a bit of a surprise when
trying to compile on some UNIXes (or other boxes) when you don't use
GCC.

But how about generally available 64-bit integers? Everyone's got to
have them, right?

No. They do NOT.
Luck has it that GCC/Linux and GCC/BSD suffers from the Microsoft
success, i.e. anyone who ain't got either is considered an, errr,
'odd' individual at the very least, but not everyone will have ANY
sort of 64-bit integer handy. The folks that don't, do not get to
compile (or use) CRM114. Ever. Fortunately that market share is
deminishing every day as PCs are dirt cheap and boxes are written off
for one reason or another, but if you want to create software for
everyone, 'long long' is a no no.

But what is that loony Ger yakking? We got int32_t et al, ain't we?

Yes. If your compiler is 100% C99 compliant. Note the '100%' , very
important, that '100%', and then also note the '99' in there.
GCC/Linux and GCC/BSD out there will have it, because every admin and
his sister on these boxes will have installed the latest stable GCC by
now. Though that is the _majority_, not _everybody_. Check the web for
trouble with older gcc versions, which are mentioned as an issue in
2008. They still happen.
Older GCC versions and VERY MANY commercial compilers (also used on
UNIXes, my dear!) are NOT 100% C99 compliant. Not because the
manufacturer is lax in upgrading the compiler (some are), but because
users MAY want to hold on to their 1000+ USD for upgrading their
development environments to the latest version. Especially in the
corporate world this is not done: you don't want to recompile all your
corporate code and purchae new copies and licenses for your
third-party licenses, just because you 'feel like upgrading your
compiler'; I've worked with an old mastodont called Visual C 6.0 as
late as 2005 and what I hear from good friends is these still live out
there. And VC6 is only one of many out there, where 'C[89]9
comformance is rated 'mostly' at the best of times.



Folks that can't handle it have left for Java. (Or better: quit the
software development business.) Once there in Java Nirvana, they now
weep in a happier world, because Java (and the whole refreshed 1960's
'virtual machine' concept (Microsoft's Dot NET, Sun's Java)) has some
other issues which, given the right customer requirements, will force
you to pay attention to the 'unwanted' platform details again anyhow,
all while you thought you did not have suffer that bit. Only then
you've got TWO layers of nastiness: the VM and the hardware proper.
Yay.




-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web: http://www.hobbelt.com/
 http://www.hebbut.net/
mail: [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php