Failing code

[jcfuller]

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

[frankie]

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).

[jcfuller]

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

[czerny]

Make a bug report!

[jcfuller]

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

[frankie]

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.

[Robert]

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 */
}

[frankie]

@ 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?

[jcfuller]

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

[Robert]

@ 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.

[frankie]

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

[jcfuller]

frankie,
  Preliminary tests are positive!
A BIG THANK YOU.

James
 

[Robert]

Thank you frankie.

[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:

Code: [Select]

#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:

Code: [Select]

    rv = DialogBoxIndirectParam( hInst,
                                    #ifndef __POCC__
                                            ( DLGTEMPLATE*) lpdp,
                                    #else
                                            (DLGTEMPLATE*)(&(lpdp->wDlgVer)),
                                    #endif
                                    0, ( DLGPROC) CallBackProc, (LPARAM) lparam);


[jcfuller]

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