My first thought was to test for a previous definition but there is no guarantee the meaning would be the same. The 'COB_' sounds good.
Curt
--- Tim Josling <te...@me...>
> wrote:
>Curt,
>Thanks for the information. How about I change them to COB_*? I
>will run a sed job on the source tree and anything I receive.
>Tim Josling
>
>
>Curt Timmerman wrote:
>>
>> I ran a quick compile/test of the tolower intrinsic on our AIX box at work and received redefinition errors on the following defines in cobr_temp_config.h:
>> UINT64_MAX
>> INT64_MAX
>> INT64_MIN
>>
>> These were previously defined in:
>> /usr/include/sys/inttypes.h
>>
>> ==
>> Curt Timmerman
>> cu...@cu...
>>
>
>_______________________________________________
>Cobolforgcc-devel mailing list
>Cob...@li...
>http://lists.sourceforge.net/mailman/listinfo/cobolforgcc-devel
==
Curt Timmerman
cu...@cu...
_____________________________________________________________
BootBox.Net - Home Of The Totally Free Internet Solution
http://www.bootbox.net
Get an @bootbox.net webmail account - http://webmail.bootbox.net
Host Your Website For Free - http://webhosting.bootbox.net
Put Your E-Commerce Business Online Virtually Free - http://bcommerce.bootbox.net
Curt,
I am just about to update the cvs with the new version, now I
have fixed the bugs I created with the global change,
Regards,
Tim Josling
Curt Timmerman wrote:
>
> My first thought was to test for a previous definition but there is no guarantee the meaning would be the same. The 'COB_' sounds good.
>
> Curt
Curt,
I have updated the cvs version changing all the int/char/float
types to COB_*. So that means that
INT32 -> COB_INT32
UINT8 -> COB_UINT8
... etc
size_t -> COB_SIZE_T
If you really need char (eg for a parm to pass to str*, then use
COB_CHAR. So
char -> COB_CHAR
This applies to all variables not just interfaces in header
files. The reason is for 64 bit CPU compatibility.
Tim Josling
Curt Timmerman wrote:
>
> My first thought was to test for a previous definition but there is no guarantee the meaning would be the same. The 'COB_' sounds good.
>
> Curt
From: Steven O. E. <so...@so...> - 2001-02-21 00:52:44
Tim,
Am I to change each instance of INT32, UINT8, etc. as indicated below in
the STRING routine and it's testing routines?
-Steven Ellis
Tim Josling wrote:
>
> Curt,
>
> I have updated the cvs version changing all the int/char/float
> types to COB_*. So that means that
>
> INT32 -> COB_INT32
> UINT8 -> COB_UINT8
> ... etc
> size_t -> COB_SIZE_T
>
> If you really need char (eg for a parm to pass to str*, then use
> COB_CHAR. So
>
> char -> COB_CHAR
>
> This applies to all variables not just interfaces in header
> files. The reason is for 64 bit CPU compatibility.
>
> Tim Josling
>
> Curt Timmerman wrote:
> >
> > My first thought was to test for a previous definition but there is no guarantee the meaning would be the same. The 'COB_' sounds good.
> >
> > Curt
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel
--
\/\/\/\/\/\/\/\/\/\/\/\/
Next time you send me an update I will make the change and send it back to you, which you should use as a base. I have a sec script to do it.
No need to duplicate this.
Regards,
Tim Josling
"Steven O. Ellis" wrote:
> Tim,
>
> Am I to change each instance of INT32, UINT8, etc. as indicated below in
> the STRING routine and it's testing routines?
>
> -Steven Ellis
>
> Tim Josling wrote:
> >
> > Curt,
> >
> > I have updated the cvs version changing all the int/char/float
> > types to COB_*. So that means that
> >
> > INT32 -> COB_INT32
> > UINT8 -> COB_UINT8
> > ... etc
> > size_t -> COB_SIZE_T
> >
> > If you really need char (eg for a parm to pass to str*, then use
> > COB_CHAR. So
> >
> > char -> COB_CHAR
> >
> > This applies to all variables not just interfaces in header
> > files. The reason is for 64 bit CPU compatibility.
> >
> > Tim Josling
> >
> > Curt Timmerman wrote:
> > >
> > > My first thought was to test for a previous definition but there is no guarantee the meaning would be the same. The 'COB_' sounds good.
> > >
> > > Curt
> >
> > _______________________________________________
> > Cobolforgcc-devel mailing list
> > Cob...@li...
> > http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel
>
> --
> \/\/\/\/\/\/\/\/\/\/\/\/
>
> _______________________________________________
> Cobolforgcc-devel mailing list
> Cob...@li...
> http://lists.sourceforge.net/lists/listinfo/cobolforgcc-devel