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-2.8.8-fix-narrow.patch
>
> 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.
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.
This code is just part of directory Testing
But your patch is to Source/Common/gdcmString.h which is not just a
test, right?
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
