Re: Validity of pointer conversions
On Jan 8, 4:01 pm, Grizlyk <grizl...@yandex.ru> wrote:
James Kanze wrote:
The standard says that all other elements will be zero. Are you
claiming that you've had problems with compiler errors in this
regard?
Default constructor for int will be called, and i have some
compilers, which do nothing in the case (a trash from previous
memory users will be found in the array). The same thing does
for pointers (int* for example).
Which compilers?
Not shure about meaning of the word "claiming", but i had a
possibilities to get the memory garbage.
Again: with which compiler? I've never seen a compiler which
got this wrong.
I have posted in the thread above description for the thrash
appearance.
The error is outside of C++ scope - within interface between
particular C++ copmiler for concrete CPU and concrete native CPU
assembler. Is it interesting here?
I'm not sure what you're point is. The fact that you can write
code in assembler which results in trash values has nothing to
do with C++. *If* the C++ compiler goes through an assembler
phase (very few do today), then it is the responsibility of the
compiler to generate assembler code which has the required
semantics.
Gcc v4.1 for x86 can create asm output with ".space".
Gcc 4.1 doesn't generate assembler; it generates object code
directly. *If* you specify the -S option, it will generate
assembler, but obviously, that assembler code "supposes" a
specific assembler, on a specific machine, which does whatever
gcc supposes it does correctly. (And of course, gcc doesn't
really document what assumptions it makes concerning the
assembler. If you generate assembler code, and then try to use
it, it's up to you to ensure that everything is correct and what
you want. As a quality of implementation issue, gcc tries to
get the assembler "right", but it's really irrelevant to
C++.)
Free bcc32 v5 for x86 can create asm output with "dup(?)"
(note, earlier versions of the compiler emit "dup(0)"
explicitly).
For ".space" it is required that 0 is by default for skipped values,
but for "dup(?)" is not.
Presumably, free bcc323 supposes a compiler (or an environment)
where dup(?) does result in 0 initialization. (Just a guess,
but I suspect that dup(0) will result in the data being laid out
in the data segment on disk, where as dup(?) will put the data
in the bss segment, with no initialization on disk---this wasn't
how the original Intel assembler worked, but it seems reasonable
for a Windows or Unix machine. Under Windows or Unix, the OS
initializes the bss to all bits 0, for security reasons, if
nothing else. And under Windows and Unix, it just happens that
zero initialization always corresponds to all bits 0.)
But in both cases some assemblers can create for dup(?) and
".space" any random values. They use "right" to do nothing for
all that was not explicitly defined, probably, in a hope to
place all the undefined values into BSS-like segments of
executable :).
And the OS's I use guarantee that all BSS-like segments are zero
initialized. (Any multi-user OS must guarantee that all memory
obtained from the system is initialized somehow---both Windows
and Unix guarantee 0.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34