Re: flags in cob_file_key

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



There are places in codegen.c which emit pointers to the cob_file and cob_file_key structures.
Also some code is emited that references those booleans...

For example:
codegen.c:                      output_storage ("static cob_file_key\t*%s%s = NULL;\n",
codegen.c:                      output_local ("static cob_file_key\t*%s%s = NULL;\n",
codegen.c:              output_storage ("static cob_file\t\t*%s%s = NULL;\n",
codegen.c:              output_local ("static cob_file\t\t*%s%s = NULL;\n",
codegen.c:              output_line ("cob_file_external_addr (\"%s\", &%s%s, %s, %d, %d);",
codegen.c:              output_line ("cob_file_malloc (&%s%s, %s, %d, %d);",
codegen.c:                              output_line ("cob_file_free (&%s%s,%s);",CB_PREFIX_FILE, fl->cname,key_ptr);                                                                     
codegen.c:              output ("%s%s->tf_duplicates = 0;\n", CB_PREFIX_KEYS, f->cname);
codegen.c:                      output ("(%s%s + %d)->tf_duplicates = %d;\n", CB_PREFIX_KEYS,
codegen.c:                      output ("(%s%s + %d)->tf_suppress = %d;\n", CB_PREFIX_KEYS,
codegen.c:                              f->cname, nkeys, l->tf_suppress);

So the code generated by the compiler must match up exactly with the code in libcob.
Since, libcob is normally a shared library that means that all programs compiled by GnuCOBOL must have matching structures referenced in the compiled COBOL modules as well as the runtime library.

On Thu, Feb 21, 2019 at 8:50 AM James K. Lowden <jklowden@xxxxxxxxxxxxxxx> wrote:
On Wed, 20 Feb 2019 16:55:20 -0800
Ron Norman <rjn@xxxxxxxxxxxx> wrote:

> Changing from 'int' to 'int xxx:1' would only require a change to the
> header file and NO code changes at all....

That's an interesting suggestion. 

As you suggest, I'll hold off until the report-writer merge. 

> You have to be very careful as make such changes could result in
> forcing a recompile of all the COBOL application code with a new
> release of the compiler.

I don't see how that would be true.  We're talking about how a file is
represented inside libcob.  The external representation (the API) and
the on-disk representation don't change.  As the symbols don't appear
in Cobol application binaries, they can't affect those binaries. 

--jkl


--
Cheers
Ron Norman

[Index of Archives]     [Gcc Help]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Info]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux