X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient: djgpp-workers AT delorie DOT com
Date: Sat, 30 Jul 2011 11:16:15 +0300
From: Eli Zaretskii <eliz AT gnu DOT org>
Subject: Re: [PATCH] allow 64 bit host tools when cross compiling
In-reply-to: <CAA2C=vBJEgnGapVsNwy7xW9HUCy0Rpxis2P5=05mxBze_qn7vQ@mail.gmail.com>
To: djgpp-workers AT delorie DOT com
Message-id: <83wrf0chf4.fsf@gnu.org>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
X-012-Sender: halo1 AT inter DOT net DOT il
References: <CAA2C=vCTyDxWBgYzoBB31=hoOBHJhL+famn_6XL2eYb3a_3egA AT mail DOT gmail DOT com> <83zkjwcknb DOT fsf AT gnu DOT org> <CAA2C=vBJEgnGapVsNwy7xW9HUCy0Rpxis2P5=05mxBze_qn7vQ AT mail DOT gmail DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by delorie.com id p6U8G7tq007052
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Sat, 30 Jul 2011 10:17:43 +0300
> From: Ozkan Sezer <sezeroz AT gmail DOT com>
> 
> >   IOW, what is the purpose of this compilation?
> 
> To compile the djgpp runtime library

Is dxegen required to be compiled and run natively for that?  (Sorry,
I have long forgotten the details of the DJGPP build process.)  If it
needs to be compiled and run natively, then I understand the need for
the changes; otherwise I do not.

> > It is mostly okay, but I don't understand why you went so far and
> > deep, and changed also the types that don't need to be changed at all.
> > For example, neither `short' nor `int' have different size on any
> > known machine that can be ever supported by DJGPP, so why change them
> > at all?
> 
> For consistency,

We don't need such a consistency in this case.  Please understand that
if you want to be consistent, you will have to make these changes all
the way through all the DJGPP library and the headers, because GCC
will complain about type mismatches if you use intNN_t where the
prototype says `int' or `long'.  (Right now, these complaints are only
emitted under certain non-default compiler switches, but with the
apparent attitude of the GCC developers that brings more and more of
such warnings into the default behavior, a day will come when the
switches we use in compiling the DJGPP library will emit these
warnings, and will then be an annoyance.)

Therefore, any use of a different type has potentially bad and
far-reaching effects, and we should strive to limit that to the
absolute minimum.  This minimum is currently only the `long' and
`unsigned long' types, so please limit the changes to these two only.
I would even use a macro instead of a stdint.h type, like this:

  #if _LP64
  # define LONG int
  # define ULONG unsigned int
  #else
  # define LONG long
  # define ULONG unsigned long
  #endf 

This will keep the x86_64 compiler happy, but OTOH will not change
what the 32-bit compiler sees at all, thus avoiding various warnings
about type mismatch.

> >> -        fwrite(&relocs[i].r_vaddr, 1, sizeof(long), outf);
> >> +        fwrite(&relocs[i].r_vaddr, 1, sizeof(int32_t), outf);
> >
> > This (and other similar) issue are better solved by using the variable
> > in question, not its type.  Like this:
> >
> >    fwrite(&relocs[i].r_vaddr, 1, sizeof(relocs[i].r_vaddr), outf);
> 
> That particular one (and its similars) I can do, if the changes
> are acceptable

They are acceptable, with the above comments taken care of.

Thanks for working on this.