[Info-vax] calloc fails with access violation

[sapienzaf]

On Aug 26, 1:03 pm, Jose Cuevas <jcue... at mac.com> wrote:
> I do see what sapienz and others are telling me about Cobols Strings.

YIPPEEEEE!!  HURRAY!!!  HALLELUJAH!!!

> Since all my tests where using "01" variables in
> Cobol, my tests did not reflected any differences.

I believe 01 level data items are aligned on quadword (8 byte)
boundaries.  So, if the length of all of your prior test strings were
not multiples of 8 bytes then there is unassigned space in memory
which follows the string itself.

I also don't believe 01 data items are guaranteed to be assigned
contiguous memory locations in the order they are declared in the
program.

In fact, this is why in my sample code using 01 level strings I
changed the string length from 20 characters to 24 characters.
Multiples of 8 bytes demonstrate that there is no zero-termination
taking place in Cobol.

You'll also notice that in that example of mine, the first string was
reported at 49 bytes, not 48 bytes (the two 24 byte strings in order),
and the second string was reported at 25 bytes instead of 24 bytes.
The 01 level ZEROBYTE item that I included clearly wasn't following
the two strings in memory.

> With the null issue at least settle for myself. I'll change my code
> over to descriptors to see if it solves the problem.

Smart move.

> PS I'll not be happy until I understand how the char * VS descriptor
> thing is messing with my calloc.

Given that the usage of the space following the strings is
indeterminate, then the run time contents can change over time.  What
is likely happening is that you are doing a STRLEN at one point in
time, and the contents of memory following that particular string
changes before the subsequent STRCPY.

That corrupts the content of the memory pool that OpenVMS uses to
assign items for CALLOC (and any other dynamic memory assignment).
The CALLOC which fails is actually not the problem.  It's a prior
STRCPY that is blowing away memory management data structures.

I suspect if you had used MEMCPY or STRNCPY instead of STRCPY the
problem may have taken a lot longer to manifest itself.

> We have another C library that we use in
> Cobol with char * and never had problems with it for about 4 years
> now.

That is unfortunate.  Some people might call it lucky, but it's not
the kind of luck that you really want.  At some point in the future
all those applications could fail with the same problem.