On Tue, Mar 27, 2012 at 22:53:47 +, Christos Zoulas wrote:
> In article <20120327202907.gt26...@bigmac.stderr.spb.ru>,
> Valeriy E. Ushakov wrote:
> >
> >But that is not what the code was. The code was:
> >
> >char c; if (c == CHAR_MAX) ...
> >
> >and *that* is portable. As I said in an
On 28 March 2012 07:53, Christos Zoulas wrote:
> In article <20120327202907.gt26...@bigmac.stderr.spb.ru>,
> Valeriy E. Ushakov wrote:
>>
>>But that is not what the code was. The code was:
>>
>> char c; if (c == CHAR_MAX) ...
>>
>>and *that* is portable. As I said in another mail to thsi thr
In article <20120327202907.gt26...@bigmac.stderr.spb.ru>,
Valeriy E. Ushakov wrote:
>
>But that is not what the code was. The code was:
>
>char c; if (c == CHAR_MAX) ...
>
>and *that* is portable. As I said in another mail to thsi thread that
>went unanswered, it is literally schizophrenic o
On Tue, Mar 27, 2012 at 20:19:41 +, Christos Zoulas wrote:
> In article
> ,
> Takehiko NOZAKI wrote:
> >-=-=-=-=-=-
> >
> >Hi,
> >
> >It seems that lint(1) is not cross build safe, it doesn't handle MD char
> >default type of sign/unsignd. See src/usr.bin/xlint/lint1/tree.c::cvtcon().
> >Th
In article ,
Takehiko NOZAKI wrote:
>-=-=-=-=-=-
>
>Hi,
>
>It seems that lint(1) is not cross build safe, it doesn't handle MD char
>default type of sign/unsignd. See src/usr.bin/xlint/lint1/tree.c::cvtcon().
>They use host MD CHAR_MAX directry ;)
>
>So, if cross building ppc/arm on other arch ca
Hi,
It seems that lint(1) is not cross build safe, it doesn't handle MD char
default type of sign/unsignd. See src/usr.bin/xlint/lint1/tree.c::cvtcon().
They use host MD CHAR_MAX directry ;)
So, if cross building ppc/arm on other arch cause false alarm , "out of
range " warnng.
Regards.
--
2012
I think that this is failure of the tests. The tests were fixed at one
point, right before the import of new version was reverted. It appears
that the re-import has not quite caught up to the pre-revert state.
On Tue, 27 Mar 2012, Jukka Ruohonen wrote:
On Tue, Mar 27, 2012 at 03:38:50PM +0
On Tue, Mar 27, 2012 at 03:38:50PM +0200, Alan Barrett wrote:
> >Mark the failing tests as broken. XXX: If no one is willing to maintain
> >the ipf tests, these should be removed.
>
> I object to this. If ipf fails its tests, then the fact should be
> made clear in the test reports, not hidden b
On 27 March 2012 22:38, Alan Barrett wrote:
> On Tue, 27 Mar 2012, Jukka Ruohonen wrote:
>>
>> Modified Files:
>> src/tests/ipf: t_filter_exec.sh t_filter_parse.sh t_nat_exec.sh
>> t_nat_ipf_exec.sh
>>
>> Log Message:
>> Mark the failing tests as broken. XXX: If no one is willing
On Tue, 27 Mar 2012, Jukka Ruohonen wrote:
Modified Files:
src/tests/ipf: t_filter_exec.sh t_filter_parse.sh t_nat_exec.sh
t_nat_ipf_exec.sh
Log Message:
Mark the failing tests as broken. XXX: If no one is willing to maintain
the ipf tests, these should be removed.
I object
10 matches
Mail list logo