> What we did with Pascal, where the differences between compilers
> was enormous, was to have different code generators for the
> different versions of Pascal.

Not what I was thinking of but I can see the sense to this approach.
This is the way I will tackle it.

>
> Yes. I have both a problem with your solution and a suggestion.
> Don't add a new library - that's killing fly with an ax. You'll
> spend the rest of your live trying to keep the two in sync.
>
> There is an entry point called isc_vax_integer (approximately) that
> inverts byte order. Look at the generated code for the C preprocessor
> and you'll see where it adds code to copy strings around. A similar
> call to the vax_integer routine will take the native format binary
> and reverse the bytes. Just generate that call for any binary data

item.

I guess the reason that I was thinking of a new library is because I
need to do this for RM/Cobol anyway. The RM/Cobol calling sequence
for external subroutines in no way resembles what a C subroutine
expects. It passes a strange activation record that provides more
information about the various arguments than you would ever want to
know. And to top it all off, the external soubroutines need to be
linked into a shared library or DLL rather than linked into the run
time directly.

>
> Have GPRE declare them to be a format that the compiler does
> understand. The engine is really good about converting among
> the data types it understands. If the chosen type is a scaled
> binary, then you'll need to generate the call to invert bytes.
> If you've got several compilers with different rules,
> you may need separate code generators (and switches) for each.
>

But don't isc_receive and isc_send expect the parameters in a certain
format that is dependent on the column type?

> Ah me. The PDP-ll COBOL compiler was originally little-endian, though
> PDP-11's were big-endian machines. It never occurred to the guy who
> did the port that there were different ways to represent integers.
> Thirty years later, it's still a problem for COBOL compilers.... We
> used to call the little-endian one COMP and the big-endian COMP-5.
> The Fortran guys thought we were idiots.
>

The trouble with the ANSI standard is that it doesn't dictate the
internal format of the various COMP data types. I can understand why
it doesn't but it does cause for confusion when dealing with multiple
compilers.


I grew up with Cobol on mainframes which were all big-endian. No
confusion. Life was so much simpler then. :)