Re: [open-cobol-list] Help understanding this behaviour

[Brian Tiffin]

Wim; yep.  Agree, and for COBOL to COBOL that'll work.  Not as easy
when mixing in other language systems though.

CALL creates a shadow structure of call parameters that can be
accessed through cob_module and even C (and anything supporting the C
ABI) can be made safe, but it requires explicit programmer
intervention when using callers or subprograms in languages other than
COBOL.  Direct calls from C to COBOL with linkage won't have any
cob_fields to reference, but the system still wants to allow for this.
 A little bit of programmer beware.

But... as Patrick found, even COBOL to COBOL requires some care and
attention of the linkage section sometimes.   :-)

Cheers,
Brian

I really really need to write up the cob_field article.  cob_field
access can really make for some powerful and safe coding.

On 9/3/13, Wim Niemans <address@hidden> wrote:
>
> Well, Brian, there are ways to circumvent.
> Occasionally I get the following error when testing my Cobol programs (not
> in openCobol):
>
> runtime error: linkage item is smaller than passed item.
>
> and, to my humble opinion, that is the way to go.
>
> Wim
>
>
>
> Op 3 sep. 2013, om 08:50 heeft Brian Tiffin het volgende geschreven:
>
>> Advanced features to the rescue.
>>
>> Wim; it isn't a bug.  It's the way of stack frames and the flexibility
>> of CALL in the C ABI landscape.  Sadly, (kinda) there is no protection
>> on sizes at runtime, unless coded for.  One I used to use was passing
>> a length, another (when calling C) is to traverse the cob_module
>> parameter space.  I still need to write up a cob_field article.  Lots
>> of power when accessing cob_field from C.
>>
>> There are pure COBOL ways though.  Patrick;
>>
>> Try ANY LENGTH on your (incoming) linkage section.  For example
>>
>>      *> Tectonics: cobc -x anylen.cob
>>      *> *********************************************
>>       identification division.
>>       program-id. anylen.
>>
>>       data division.
>>       working-storage section.
>>       01 some-string pic x(40) value "testing 1 2 3".
>>
>>      *> *********************************************
>>       procedure division.
>>       call "subprogram" using some-string end-call
>>       call "subprogram" using "test" end-call
>>       goback.
>>       end program anylen.
>>
>>      *> *********************************************
>>       identification division.
>>       program-id. subprogram.
>>
>>       data division.
>>       linkage section.
>>       01 some-string pic x any length.
>>
>>       procedure division using some-string.
>>       display
>>           function length(some-string) ": #" some-string "#"
>>       end-display
>>       goback.
>>       end program subprogram.
>>
>> $ cobc -x anylen.cob
>> $ ./anylen
>> 00000040: #testing 1 2 3                           #
>> 00000004: #test#
>>
>> Cheers,
>> Brian
>>
>> On 9/2/13, Wim Niemans <address@hidden> wrote:
>>>
>>> To me, this looks like a serious bug in the compiler, because it should
>>> perform a length check.
>>> When this string is longer, there seem to be no problem and I guess
>>> everybody will understand that and refer to the distinct picture
>>> clauses.
>>> When this string is shorter, however, Cobol should definite issue a error
>>> or
>>> warning, because it otherwise facilitates a security leak.
>>> The only defense that can be used is the mismatch of BY VALUE / BY
>>> REFERENCE
>>> in the the caller and the callee.
>>>
>>> Wim
>>>
>>>
>>>
>>> Op 2 sep. 2013, om 05:09 heeft Patrick het volgende geschreven:
>>>
>>>> Hi Charles, Hello Paul, Hi Michael
>>>>
>>>> This all makes sense now. The "problem" is actually on the receiving
>>>> end
>>>> where a sort of buffer overflow occurs when the additional memory
>>>> locations are read due to the mismatched values.
>>>>
>>>> I suppose in production code, it's not very often that someone would
>>>> just want to send a string in quotes only anyways. I am probably
>>>> getting
>>>> tripped up with quick mock up code.
>>>>
>>>> This information will help a lot, getting used to the PIC based type
>>>> system takes a bit of time but I think I am well on my way now.
>>>>
>>>> Have a great night guys !
>>>>
>>>> -Patrick
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>>> Discover the easy way to master current and previous Microsoft
>>>> technologies
>>>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>>>> tutorial videos with LearnDevNow. Subscribe today and save!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> open-cobol-list mailing list
>>>> address@hidden
>>>> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>> Discover the easy way to master current and previous Microsoft
>>> technologies
>>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>>> tutorial videos with LearnDevNow. Subscribe today and save!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> open-cobol-list mailing list
>>> address@hidden
>>> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>>>
>>
>> ------------------------------------------------------------------------------
>> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>> Discover the easy way to master current and previous Microsoft
>> technologies
>> and advance your career. Get an incredible 1,500+ hours of step-by-step
>> tutorial videos with LearnDevNow. Subscribe today and save!
>> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>> _______________________________________________
>> open-cobol-list mailing list
>> address@hidden
>> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>
>