On Tue, 2019-02-26 at 20:52 +0000, Jonathan Wakely wrote:
On 26/02/19 19:42 +0000, Sérgio Basto wrote:
> On Tue, 2019-02-26 at 14:46 +0000, Jonathan Wakely wrote:
> > On 26/02/19 13:28 +0100, Florian Weimer wrote:
> > > * Sérgio Basto:
> > >
> > > > The key was "can't represent -1 with an unsigned
number" , I
> > > > add
> > > > some sign char to the code [1] and it fix the FTBFS
> > > >
> > > > Thanks ,
> > > >
> > > > [1]
> > > >
>
>
https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-...
> > >
> > > Please note that this patch changes the mangled names of
> > > template
> > > instantiations and thus breaks ABI. I'm not sure if this
> > > appropriate
> > > for a Fedora downstream-only patch, but maybe it's okay based
> > > on
> > > what
> > > the package does.
> >
> > I was going to say the same thing. It looks very wrong to me.
> >
> > It would be better to fix the use of the class, not the
> > definition of
> > the class. i.e. change String<EOF, ...> to String<(char)EOF,
> > ...>.
> >
> > Or stop assuming that EOF can fit in a character type and use
> > something like String<(char)-1, ...> instead. Otherwise if EOF
> > happens
> > to be a value like -191 then (char)EOF will produce the character
> > 'A'
> > which is probably not what it wants as a delimiter. EOF isn't
> > going
> > to
> > equal -191 for glibc, but it's still bogus to use EOF there IMO.
>
> Is stdio.h that defines EOF as -1 , so if we what work with files
> and
> use EOF character, we need use signed chars, though .
I don't understand what you're saying here, sorry.
stdio.h defines EOF as -1 , so if we want work with files
and use EOF character, we need use signed chars, though .
If you're saying any code using files needs to use signed char,
that's
not true. You just need to stop trying to use EOF where a char is
needed. EOF is not a char, it's an int.
ok
> This code is just part of directory Testing
But your patch is to Source/Common/gdcmString.h which is not just a
test, right?
aah yes now I understood the point .
Thanks,
--
Sérgio M. B.