Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
* Sérgio Basto: > OK , I made another patch [1] not touching ./Source/Common/gdcmString.h > and instead use definition of EOL, I use the default char of template > ... > > [1] > > https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-dont_use_EOF.patch That looks much more reasonable. Thanks! Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Tue, 2019-02-26 at 22:44 +0100, Florian Weimer wrote: > * Sérgio Basto: > > > stdio.h defines EOF as -1 , so if we want work with files > > and use EOF character, we need use signed chars, though . > > No, this is not how it works. > > Most C interfaces (hopefully all of them, but I wouldn't be sure) > that > use in-band signaling for EOF return ints. EOF is returned as int, > and > the characters are returned after casting them to unsigned char, even > if > char is signed on the architecture. > > So getchar returns 255 when reading the character 'ÿ' in ISO-8859-1, > and > -1 for EOF. > > It is a common mistake to use a char variable to store the result of > getchar and similar functions because this way, you cannot tell 'ÿ' > and > EOF apart. This leads either to premature detection of EOF, or > infinite > loops reading 'ÿ' over and over again, depending on the architecture. OK , I made another patch [1] not touching ./Source/Common/gdcmString.h and instead use definition of EOL, I use the default char of template ... [1] https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-dont_use_EOF.patch > Thanks, > Florian -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
* Sérgio Basto: > stdio.h defines EOF as -1 , so if we want work with files > and use EOF character, we need use signed chars, though . No, this is not how it works. Most C interfaces (hopefully all of them, but I wouldn't be sure) that use in-band signaling for EOF return ints. EOF is returned as int, and the characters are returned after casting them to unsigned char, even if char is signed on the architecture. So getchar returns 255 when reading the character 'ÿ' in ISO-8859-1, and -1 for EOF. It is a common mistake to use a char variable to store the result of getchar and similar functions because this way, you cannot tell 'ÿ' and EOF apart. This leads either to premature detection of EOF, or infinite loops reading 'ÿ' over and over again, depending on the architecture. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
* Tom Hughes: > On 26/02/2019 19:42, Sérgio Basto wrote: > >> 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 . > > No, you need to use int. The EOF value is deliberately outside the > range of character values so that EOF is not a valid character! EOF is a valid character, 'ÿ', in the Latin-1 encoding on x86 and various other architectures. On those architectures, EOF and 'ÿ' have the same type and value as far as the C language is concerned. (In C++, character literals have type char, so the types are different.) Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Tue, 2019-02-26 at 20:52 +, Jonathan Wakely wrote: > On 26/02/19 19:42 +, Sérgio Basto wrote: > > On Tue, 2019-02-26 at 14:46 +, 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 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On 26/02/19 19:42 +, Sérgio Basto wrote: On Tue, 2019-02-26 at 14:46 +, 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 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On 26/02/2019 19:42, Sérgio Basto wrote: 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 . No, you need to use int. The EOF value is deliberately outside the range of character values so that EOF is not a valid character! If you look at the stdio functions that can return EOF you will find that they all use int not char... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Tue, 2019-02-26 at 14:46 +, 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 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 . This code is just part of directory Testing > -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
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 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
* 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. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Mon, 2019-02-25 at 09:58 -0500, Adam Jackson wrote: > On Fri, 2019-02-22 at 19:59 +, Sérgio wrote: > > Add -fsigned-char fix the build thanks, I still not understood, why > > only ppc64le and GCC 9 > > I can't speak to the gcc9 part, but this would probably have failed > on > aarch64 and s390x as well, you just didn't notice because those > aren't > arches in copr. yes , I could check this on koji , aarch64 and others also failed to build. > C's "char" type is either signed or unsigned by default, it's a > function of the processor-specific ABI. It happens to be signed on > i686 > and x86_64, and unsigned on all the other arches Fedora supports. So: > > > /builddir/build/BUILD/gdcm- > > 2.8.8/Testing/Source/Common/Cxx/TestString2.cxx:29:24: error: > > narrowing conversion of '-1' from 'int' to 'char' [-Wnarrowing] > > This would only trigger on unsigned-char arches, because you can't > represent -1 with an unsigned number. 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 > - ajax > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Fri, 2019-02-22 at 19:59 +, Sérgio wrote: > Add -fsigned-char fix the build thanks, I still not understood, why > only ppc64le and GCC 9 I can't speak to the gcc9 part, but this would probably have failed on aarch64 and s390x as well, you just didn't notice because those aren't arches in copr. C's "char" type is either signed or unsigned by default, it's a function of the processor-specific ABI. It happens to be signed on i686 and x86_64, and unsigned on all the other arches Fedora supports. So: > /builddir/build/BUILD/gdcm-2.8.8/Testing/Source/Common/Cxx/TestString2.cxx:29:24: > error: narrowing conversion of '-1' from 'int' to 'char' [-Wnarrowing] This would only trigger on unsigned-char arches, because you can't represent -1 with an unsigned number. - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
Add -fsigned-char fix the build thanks, I still not understood, why only ppc64le and GCC 9 A 22 de fevereiro de 2019 07:05:25 WET, Florian Weimer escreveu: >* Jerry James: > >> On Thu, Feb 21, 2019 at 7:28 PM Sérgio Basto >wrote: >>> Hi, >>> I'm trying fix a FTBFS of gdcm , but just in ppc64le rawhide I have >one >>> strange compile error [1] which I can't find a solution, all logs >where >>> [2] . Can someone help me to fix it ? >> >> I think you need to add -fsigned-char to the build flags. The >> compiler complaints make sense if char is unsigned. > >Using EOF as a character is pretty much always wrong. Fortunately, >this >appears to be just a broken test, so it should be easy to fix for >upstream. > >Thanks, >Florian >___ >devel mailing list -- devel@lists.fedoraproject.org >To unsubscribe send an email to devel-le...@lists.fedoraproject.org >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@lists.fedoraproject.org -- Enviado a partir do meu dispositivo Android com o K-9 Mail. Peço desculpa pela brevidade.___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
* Jerry James: > On Thu, Feb 21, 2019 at 7:28 PM Sérgio Basto wrote: >> Hi, >> I'm trying fix a FTBFS of gdcm , but just in ppc64le rawhide I have one >> strange compile error [1] which I can't find a solution, all logs where >> [2] . Can someone help me to fix it ? > > I think you need to add -fsigned-char to the build flags. The > compiler complaints make sense if char is unsigned. Using EOF as a character is pretty much always wrong. Fortunately, this appears to be just a broken test, so it should be easy to fix for upstream. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?
On Thu, Feb 21, 2019 at 7:28 PM Sérgio Basto wrote: > Hi, > I'm trying fix a FTBFS of gdcm , but just in ppc64le rawhide I have one > strange compile error [1] which I can't find a solution, all logs where > [2] . Can someone help me to fix it ? I think you need to add -fsigned-char to the build flags. The compiler complaints make sense if char is unsigned. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
