Subject: Re: libradius broken on amd64
To: Martin Husemann <martin@duskware.de>
From: Paulo Alexandre Pinto Pires <p@ppires.org>
List: current-users
Date: 02/20/2005 17:45:34
This is a multi-part message in MIME format.
--------------020406020406000703020800
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Martin Husemann wrote:
>On Sun, Feb 20, 2005 at 12:46:03PM -0300, Paulo Alexandre Pinto Pires wrote:
>
>
>>Hello.
>>
>>While trying to cross-build an amd64 release from sources as of today
>>(2005/02/20), I got a bunch of lint errors that prevented it to go
>>successfully.
>>
>>
>
>I just removed the -w from LINTFLAGS - so it won't error on this warnings
>now.
>
>
>
>> Most (all?) errors seemed related to the assumption that
>>sizeof(int)==sizeof(long), which isn't true for 64-bit gcc. Building
>>the same sources natively on i386 runs smoothly to the end.
>>
>>
>
>No, most of the warnings looked like stupid lint bugs to me. At least enough
>that it made no sense to actually look for 64bit cleaness in the tons
>of warnings ;-)
>
>
<>
<>I think lint was just doing its job, alerting about potential problems
that could arise from accuracy lossage and possibly misaligned pointer
casts/arithmetic, for pointed-to variables of different size. Since
lint doesn't really run the program it is checking, it cannot be sure if
the lost/misaligned bits will affect the result of the computation or
not. If we can be sure that they don't, there are other ways of keeping
lint silent, without simply ignoring warnings.
I understand that getting absolutely all the code to compile without
warning on every platform is a huge task, especially for third-party
code that gets into the tree, which sometimes come from people working
on systems strongly biased to a specific architecture, where int, long
and int32_t can be used interchangebly. However, as we like to have
code that is "right", NetBSD will benefit from fixing those pieces of
code, and everybody else will also benefit if changes are sent
contributed back to the original code writers.
<>
--
Pappires
... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
--------------020406020406000703020800
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Martin Husemann wrote:
<blockquote cite="mid20050220163157.GI12857@drowsy.duskware.de"
type="cite">
<pre wrap="">On Sun, Feb 20, 2005 at 12:46:03PM -0300, Paulo Alexandre Pinto Pires wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello.
While trying to cross-build an amd64 release from sources as of today
(2005/02/20), I got a bunch of lint errors that prevented it to go
successfully.
</pre>
</blockquote>
<pre wrap=""><!---->
I just removed the -w from LINTFLAGS - so it won't error on this warnings
now.
</pre>
<blockquote type="cite">
<pre wrap=""> Most (all?) errors seemed related to the assumption that
sizeof(int)==sizeof(long), which isn't true for 64-bit gcc. Building
the same sources natively on i386 runs smoothly to the end.
</pre>
</blockquote>
<pre wrap=""><!---->
No, most of the warnings looked like stupid lint bugs to me. At least enough
that it made no sense to actually look for 64bit cleaness in the tons
of warnings ;-)
</pre>
</blockquote>
<p><></></p>
<p><>I think lint was just doing its job, alerting about potential
problems that could arise from accuracy lossage and possibly misaligned
pointer casts/arithmetic, for pointed-to variables of different size.
Since lint doesn't really run the program it is checking, it cannot be
sure if the lost/misaligned bits will affect the result of the
computation or not. If we can be sure that they don't, there are other
ways of keeping lint silent, without simply ignoring warnings.<br>
</></p>
<p>I understand that getting absolutely all the code to compile without
warning on every platform is a huge task, especially for third-party
code that gets into the tree, which sometimes come from people working
on systems strongly biased to a specific architecture, where int, long
and int32_t can be used interchangebly. However, as we like to have
code that is "right", NetBSD will benefit from fixing those pieces of
code, and everybody else will also benefit if changes are sent
contributed back to the original code writers.<br>
<></></p>
<pre class="moz-signature" cols="72">--
Pappires
... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
</pre>
</body>
</html>
--------------020406020406000703020800--