Appreciate your delightful sense of humour, it indeed cheered me up. The
information isn't private at all, at first I thought the function is
pretty lengthy to be posted here, therefore I provided just a snippet as
you asked. I've posted the source of the routine under question at
http://clc.pastebin.com/f4FRqgit
Well, you've moved past dribbling, but in order to help you we still
need more information than you've given so far. What you should give us
is the complete actual text of a stand-alone program (preferably as
small as possible) that can actually be compiled and executed to
demonstrate the problem you're asking about. You should identify the
environment where you compiled, linked, and executed the program, and
the precise commands you used to do the compiling an linking.
Your code is not compilable as it stands because it uses the following
identifiers without defining or declaring them, and also without
#including a header file that would define or declare them:
bool
crc_ver_init
embedded_nvram
magic
nvram_exit
nvram_do_reset
nvram_header
struct nvram_header
printf
si_t
uint32
FALSE
FLASH_MIN
KSEG1ADDR
NVRAM_MAGIC
NVRAM_SPACE
SI_FLASH2
SI_FLASH2_SZ
TRUE
It's possible to make reasonable guesses about what those identifiers
might mean, based both upon their names and upon how they are used.
However, the peculiar behavior of your program could easily depend upon
precisely how one of those identifiers is defined. In particular, if
you've made a mistake by using one of those identifiers in a way that's
incompatible with the way it's defined, that might be precisely whey the
behavior is so odd.
The behavior is undefined because the code makes use of the following
identifiers which are reserved to the implementation:
_nvram_init
_nvram_exit
If these are routines defined by the implementation, and used by your
program, then your program is portable only to implementations that
provide definitions for those identifiers which work in the way you
expect them to. You should identify where the definitions of those
functions comes from.
The fact that one of the two functions whose definition you have
provided is named nvram_init() opens up the question of whether
_nvram_init might be a typo for nvram_init (or vice versa).
Your code fails to demonstrate the problem because it does not, in
itself, constitute a complete program. That can easily be solved by
adding a main() which calls nvram_init(). However, you need to provide
us with that call; the reason why you're getting the odd results that
you see might be due to the context from which it was called.