Compile problem ov.cc of octave-3.1.51 on cygwin

[Jaroslav Hajek]

On Wed, Jul 30, 2008 at 8:28 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
> On Tue, Jul 29, 2008 at 10:56 PM, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
>> On 29-Jul-2008, Jaroslav Hajek wrote:
>>
>> | On Tue, Jul 29, 2008 at 10:10 AM, Tatsuro MATSUOKA
>> | <tmacchant at yahoo.co.jp> wrote:
>> | > Hello Jaroslav Hajek
>> | >
>> | > With your patch, ov.cc complie problem ov.cc is resolved for cygwin.
>> | >
>> |
>> | Good. John, can you apply this?
>>
>> Did you see my earlier reply?
>>
>> https://www.cae.wisc.edu/pipermail/bug-octave/2008-July/006394.html
>>
>> I asked whether there should maybe be at least a warning for values
>> that are out of range.
>>
>> jwe
>>
>
> Sorry, I attributed the question to my suggestion that octave_int<T>
> should be convertible to default int. The attached patch adds a
> safe_conversion method to octave_int<T> and uses it in
> convert_to_int_array. Is this what you meant?
> However, caling, for instance, int8_array_value () on an octave_value
> object containing a 32-bit int array does not gripe either. Perhaps we
> could make the octave_int<T>:: octave_int(const octave_int<U>&)
> constructor gripe if data need to be truncated.
> In this way, the octave_int<> types would act as "conversion-safe
> integers" contrary to the normal, unsafe integers. I think, however,
> that a mechanism to avoid multiple gripes from loops would be needed
> in such case.
>
> --
> RNDr. Jaroslav Hajek
> computing expert
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz
>

Please forget drop this patch. I've put together a better (IMHO)
solution that adds int-to-int conversion checks to many more places.
See the other thread on maintainers ML.

regards

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz