The attached code compiles and runs fine but fails when even the first commented line is uncommented.
With uncommented lines it compiles and runs fine as a "c" app with:
Visual Studio 2013 32/64
TDM-GCC 32/64
TinyC 32/64
NUWEN MINGW (64 only)
Only fails with PellesC (latest release but I did try with an earlier one and it still failed) ????
James
Can't see exactly what the error is, but I suppose that the problem is the use of _msize.
In PellesC this function doesn't returns the exact allocated space in bytes (as clearly stated in the help), so the way you use it the failure is sure :(
To make work your code in PellesC you have to keep trace yourself of space allocated or use the OS memory functions (heap functions or GlobalAlloc and relatives).
Thanks for the heads up frankie.
It is a shame that PellesC is the only one that returns block size instead of actual size?
James
Make a bug report!
There are reports and trolled forum posts that go back to 2005 on the difference of PellesC and the rest of the compilers re _msize. It appears it's not very high on the to to list if it is there at all??
James
This is not a bug, but _msize works this way by design as clearly explained in help. :-[
I agree with you that the MS behaviour of _msize is preferable, so if you like I can move this in the feature requests thread.
Quote from: frankie on February 16, 2015, 04:28:04 PM
This is not a bug, but _msize works this way by design as clearly explained in help. :-[
I agree with you that the MS behaviour of _msize is preferable, so if you like I can move this in the feature requests thread.
//
// VStudio 2015 32 bit compiled run of the code below outputs
//
// 4
// 10256
// 2048
// Crash-hang!!!
//
// VStudio 2015 64 bit compiled run of the code below outputs
//
// 8
// 10256
// 2048
// Crash-hang!!!
//
// Pelles C 8 RC 7 32 bit compiled run of the code below outputs
//
// 4
// 10259
// 2048
// 0
//
// Pelles C 8 RC 7 64 bit compiled run of the code below outputs
//
// 8
// 10263
// 2048
// Crash-hang!!!
//
#include <stdio.h> // dos/linux
#include <string.h> // dos/linux
#include <stdlib.h> // dos/linux
#define cSizeOfDefaultString 2048
static char *Achar;
static int SizeofAchar;
static int msizeAchar;
static int SizeofA;
static int msizeA;
static char A[cSizeOfDefaultString];
int main(int argc, char *argv[])
{
Achar=(char*)calloc(256+10000 ,1);
SizeofAchar= sizeof( Achar);
printf("% d\n",(int)SizeofAchar);
msizeAchar=_msize( Achar);
printf("% d\n",(int)msizeAchar);
SizeofA= sizeof( A);
printf("% d\n",(int)SizeofA);
msizeA=_msize( A);
printf("% d\n",(int)msizeA);
return 0; /* End of main program */
}
@ Robert: and point is? ??? ???
You are using _msize on a local variable: PellesC crashes, MSVC throw an exception.
sizeof operator applied to a pointer will give you the size of the pointer not the memory allocated, PellesC_msize give you the space allocated in blocks.
sizeof of a static array will give you the memory used from the array.... and so on.
The only anomaly I see is that Pelles C 8 RC 7 32 bit don't hang. ;) Yes this could be a bug.
Have I well understood? Please could you be more clear?
frankie,
I realize it is not a bug but a design decision (poor in my opinion; but what do I know) so I will list it as a feature when stating why PellesC can no longer be used with the bc9Basic translator.
You must have noticed in the code it is not mine so changing it is not an option. I barely understand Jeffrey Richter's code as it is.
James
Quote from: frankie on February 16, 2015, 05:10:54 PM
@ Robert: and point is? ??? ???
You are using _msize on a local variable: PellesC crashes, MSVC throw an exception.
sizeof operator applied to a pointer will give you the size of the pointer not the memory allocated, PellesC_msize give you the space allocated in blocks.
sizeof of a static array will give you the memory used from the array.... and so on.
The only anomaly I see is that Pelles C 8 RC 7 32 bit don't hang. ;) Yes this could be a bug.
Have I well understood? Please could you be more clear?
On April 10 2014 frankie said at
http://forum.pellesc.de/index.php?topic=6154.msg22557#msg22557
"Anyway _msize as per MS definition, that PellesC follows in this case, returns the size of blocks allocated not the bytes requested (see https://msdn.microsoft.com/en-us/library/z2s077bc.aspx)."
In the example I posted
Pelles C 8 RC 7 32 bit _msize returns 10259
VStudio 2015 32 bit _msize returns 10256
Pelles C 8 RC 7 64 bit _msize returns 10263
VStudio 2015 64 bit _msize returns 10256
It seems to me that PellesC does not follow the MS definition. I don't want to start arguing semantics about whether "definition" is or is not the same as "implementation".
I know that the _msize function implementation is compiler dependent and the Pelle has clearly stated that
"The size of the allocated object (which may be slightly larger than the size given when allocating the object, due to internal housekeeping)."
The problem James Fuller stated in his original post still remains. Jeremy Richter's code fails with Pelles C and I tried to provide a simple example which may provide a clue to this failure.
If my posts in this thread are useless clutter then please delete them.
Robert you're perfectly right. Unfortunately Pelle is of different idea. :-[
I would clearly state that I agree that _msize should return something that make sense or it is useless! >:(
Waiting for Pelle to consider it.
James below there is a patch for your compiler that still allows the compilation using PellesC, if you and people from bc9 want consider it it could work for a while. My patches are between the #ifdef __POCC_ or #ifndef __POCC__.
EDIT: I removed some rubbish put during tests, from files
frankie,
Preliminary tests are positive! ;D
A BIG THANK YOU.
James
Thank you frankie.
Thanks :)
Please consider that this code works for any compiler that have a broken _msize or is missing it (not only for PellesC).
If there are other places where _msize is used let me know I will try to patch it.
BTW to make my patch more elegant and compact in bc9dialog2.c function 'BC9_DlgShowModal' please replace lines:
#ifdef __POCC__
//Fix pointer for PellesC to skip the size
lpdp = (void *)(((char *)lpdp)+sizeof(size_t));
#endif
rv = DialogBoxIndirectParam( hInst, ( DLGTEMPLATE*) lpdp, 0, ( DLGPROC) CallBackProc, (LPARAM) lparam);
#ifdef __POCC__
//Fix pointer for PellesC to skip the size
lpdp = (void *)(((char *)lpdp)-sizeof(size_t));
#endif
With:
rv = DialogBoxIndirectParam( hInst,
#ifndef __POCC__
( DLGTEMPLATE*) lpdp,
#else
(DLGTEMPLATE*)(&(lpdp->wDlgVer)),
#endif
0, ( DLGPROC) CallBackProc, (LPARAM) lparam);
Quote from: frankie on February 17, 2015, 10:14:57 AM
Please consider that this code works for any compiler that have a broken _msize or is missing it (not only for PellesC).
frankie,
I have not found another compiler where _msize is broken including one missing from my original list: lcc.
Again, thank you very much for the fix.
James
I created a compiler patch for the broken _msize.
You can find it here (http://forum.pellesc.de/index.php?topic=6622.0).
frankie,
Did you try it with the original code example I posted?
It fails here.
James
Quote from: jcfuller on February 20, 2015, 12:02:35 PM
frankie,
Did you try it with the original code example I posted?
It fails here.
Hi James
I used your code to test in 32 and 64 bits. Please find attached the demo project.
Maybe you included the header in the wrong place. Remember it must be always the last system header that you include.Please let me know.
EDIT: Ok I got it! My wrong, in the usage description I was not clear enaugh. The former version must have been included after the last
system header, not the last header... :( The situation got even worst because you include a C file (that while formally correct should be avoided in C).
So to keep it simple I made a decision to change the code. The new version must be the very first header in your code, can even preceed the system definitions.
I have already updated the patch (http://forum.pellesc.de/index.php?topic=6622.0), and the code below.
frankie,
Thanks again for your support but....
I do not do things the conventional way. I know I should have multiple modules but that's a bit of a PIA as I compile with batch files. Just an -m32 or -m64 and I have 32/64.
What I have done and might be an alternate approach for you too is to create a 32/64 static library from pellescmem.c and put them in the appropriate win/win64 lib folders.
Now with #include <pellescmem.h> at the top and a #pragma comment(lib,"pellescmem.lib") it seems to work fine.
Do you see any problems with this approach?
James
Quote from: jcfuller on February 20, 2015, 03:58:44 PM
What I have done and might be an alternate approach for you too is to create a 32/64 static library from pellescmem.c and put them in the appropriate win/win64 lib folders.
Now with #include <pellescmem.h> at the top and a #pragma comment(lib,"pellescmem.lib") it seems to work fine.
Do you see any problems with this approach?
James
James,
it is an absolutely legitimate solution. I've not created a library because is such a small code ... you know. :)
Your approach works much better when compiling sources with different compilers, enclose the header between an ifdef:
#ifdef __POCC__
#include "pellescmem.h"
#endif
and ... voilà! ;D