On Wed, 2007-10-31 at 00:42 -0700, Erick Tryzelaar wrote:
> No one seems to like how you're getting the stack pointer:
> windows:
> z:\felix.git\lpsrc\flx_rtl.pak(2567) : warning C4172: returning
> address of local variable or temporary
>
> osx:
> ../felix.git/lpsrc/flx_rtl.pak: In function 'void* get_stack_pointer()':
> ../felix.git/lpsrc/flx_rtl.pak:2554: warning: address of local
> variable 'x' returned
These are warnings. It is possible this is not conforming C/C++,
but that is too bad: C/C++ are deficient languages, the use
of what it thinks are unsafe features is precisely to compensate
for these weakness with a garbage collector.
This case could be fixed by fooling the compiler, by, for example:
void *get_stack_pointer() {
int x;
void *px = &x;
return px;
}
Now, we're returning a pointer, but the compiler needs to be smart
to realise it is a pointer onto the stack.. unfortunately this
may also cost a bit.
> windows doesn't like how there's not a corresponding delete for a new:
> z:\felix.git\lpsrc\flx_rtl.pak(2586) : warning C4291: 'void *operator
> new(size_t,flx::gc::generic::gc_profile_t
> &,flx::gc::generic::gc_shape_t &,bool)' : no matching operator delete
> found; memory will not be freed if initialization throws an exception
> z:\felix.git\lpsrc\flx_gc.pak(320) : see declaration of 'operator new'
> z:\felix.git\lpsrc\flx_rtl.pak(2594) : warning C4291: 'void *operator
> new(size_t,flx::gc::generic::gc_profile_t
> &,flx::gc::generic::gc_shape_t &,bool)' : no matching operator delete
> found; memory will not be freed if initialization throws a n exception
> z:\felix.git\lpsrc\flx_gc.pak(320) : see declaration of 'operator new'
In Felix, of an exception is thrown,
we do not CARE if the storage is freed because exceptions always
terminate the program. But even if the exception is caught,
the compiler is wrong.. the storage WILL be freed, because the
operator new didn't terminate, so there is no record of the
pointer to the object, and so it is unreachable, and will be collected!
The real problem is that if the exception is thrown the object
will be in an inconsistent state, but the collector will still
run the finaliser, which is typically the destructor.
If there is no delete, what happens? (need to check standard ..)
Hmm .. should there be a delete?
In Felix, the object is linked into the gc BEFORE the
C++ constructor is run. If the constructor throws,
and cleans up the object automatically, then using
a delete function to remove the object from the Judy
array and free the memory makes sense, since it would
stop the gc running the finaliser.
I think, pending a check on the ISO Standard here, we might
need to supply the operator delete anyhow: even though exceptions
general trash the program, we should get this right locally in
case one day exceptions are used.
>
> osx doesn't like how -1 is specified for a couple places where the
> argument is unsigned int. I assume this was done to be a hack way
> around specifying the max integer:
>
> g++ -c -g -O3 -fomit-frame-pointer --inline -Irtl -o
> test/drivers/flx_perf_drv1_dynamic.o -DTARGET_BUILD
> test/drivers/flx_perf_drv1.cxx
> ../felix.git/lpsrc/flx_test.pak: In function 'int main(int, char**)':
> ../felix.git/lpsrc/flx_test.pak:231: warning: passing negative value
> '-0x00000000000000001' for argument 5 to
> 'flx::gc::generic::gc_profile_t::gc_profile_t(bool, bool, bool, long
> unsigned int, long unsigned int, long unsigned int, double, bool,
> flx::gc::generic::collector_t*)'
Yes, I think so.. note flx_test.pak is really just a hacked
up performance test, not real code, so this one doesn't really
matter.
> ../felix.git/lpsrc/flx_rtl.pak:2970: warning: passing negative value
> '-0x00000000000000001' for argument 5 to
> 'flx::gc::generic::gc_profile_t::gc_profile_t(bool, bool, bool, long
> unsigned int, long unsigned int, long unsigned int, double, bool,
> flx::gc::generic::collector_t*)'
> ../felix.git/lpsrc/flx_rtl.pak:2970: warning: passing negative value
> '-0x00000000000000001' for argument 6 to
> 'flx::gc::generic::gc_profile_t::gc_profile_t(bool, bool, bool, long
> unsigned int, long unsigned int, long unsigned int, double, bool,
> flx::gc::generic::collector_t*)'
But these probably do..
HOWEVER there is a FAR worse problem ;(
I am using '(unsigned) long' as a 'large number' in many
places, where I SHOULD be using an (unsigned or signed)
size_t, ptrdiff_t, FLX_RAW_ADDRESS, intptr_t or whatever.
In these places the code may fail on XP64, since void*
is 64 bits, and the fat integer is 'long long' not 'long'.
This needs to be fixed!! See for example the garbage collector
methods (all using longs).
I think I did this because otherwise it would be hard
to make the routines visible in Felix, however the new
typeset/constraints stuff should handle this now.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
