From: Bollinger, J. C <John.Bollinger@STJUDE.ORG> - 2011-09-20 21:13:47
|
Hello All, As I wrote a few minutes ago, I am attempting to build PDFedit v 0.4.5 on CentOS 5, using the distro's provided GCC 4.1.2 toolchain. The method CPageContents::addInlineImage() is giving me some trouble, the bulk of which I raised in my previous mail. In addition, however, I see some worrisome warnings in the same method: g++ -c -g -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fexceptions -fstack-protector -pipe -posix -ansi -std=c++98 -pedantic -I. -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/ -I/usr/include -I/usr/include/freetype2 -I/usr/include -o cpagecontents.o cpagecontents.cc cpagecontents.cc: In member function 'void pdfobjects::CPageContents::addInlineImage(const std::vector<char, std::allocator<char> >&, const libs::Point&, const libs::Point&)': cpagecontents.cc:543: warning: passing 'const double' for argument 1 to 'pdfobjects::CObjectSimple<Tp>::CObjectSimple(const typename pdfobjects::PropertyTraitSimple<Tp>::value&) [with pdfobjects::PropertyType Tp = pInt]' [...] cpagecontents.cc:544: warning: passing 'const double' for argument 1 to 'pdfobjects::CObjectSimple<Tp>::CObjectSimple(const typename pdfobjects::PropertyTraitSimple<Tp>::value&) [with pdfobjects::PropertyType Tp = pInt]' These arise from the following two lines of code: image_dict.addProperty ("W", CInt (image_size.x)); image_dict.addProperty ("H", CInt (image_size.y)); Evidently, image_size.x and image_size.y are of type (const double), but they are passed to a constructor expecting an int&. I'm neither sure what is needed, nor sure what actually happens here (and that in itself is a minor problem). Given that we're dealing with references, however, I can't think of an approach the compiler could take to the issue that would be likely to have a satisfactory result. The most obvious fix would be to change the CInts to CReals, but I don't know whether that would cause trouble elsewhere in the program. Best, John Bollinger Email Disclaimer: www.stjude.org/emaildisclaimer |
From: Jeffrey W. <nol...@gm...> - 2011-09-20 21:35:36
|
On Tue, Sep 20, 2011 at 5:13 PM, Bollinger, John C <Joh...@st...> wrote: > Hello All, > > As I wrote a few minutes ago, I am attempting to build PDFedit v 0.4.5 on CentOS 5, using the distro's provided GCC 4.1.2 toolchain. The method CPageContents::addInlineImage() is giving me some trouble, the bulk of which I raised in my previous mail. In addition, however, I see some worrisome warnings in the same method: > > g++ -c -g -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fexceptions -fstack-protector -pipe -posix -ansi -std=c++98 -pedantic -I. -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/ -I/usr/include -I/usr/include/freetype2 -I/usr/include -o cpagecontents.o cpagecontents.cc > cpagecontents.cc: In member function 'void pdfobjects::CPageContents::addInlineImage(const std::vector<char, std::allocator<char> >&, const libs::Point&, const libs::Point&)': > cpagecontents.cc:543: warning: passing 'const double' for argument 1 to 'pdfobjects::CObjectSimple<Tp>::CObjectSimple(const typename pdfobjects::PropertyTraitSimple<Tp>::value&) [with pdfobjects::PropertyType Tp = pInt]' > [...] > cpagecontents.cc:544: warning: passing 'const double' for argument 1 to 'pdfobjects::CObjectSimple<Tp>::CObjectSimple(const typename pdfobjects::PropertyTraitSimple<Tp>::value&) [with pdfobjects::PropertyType Tp = pInt]' > > These arise from the following two lines of code: > > image_dict.addProperty ("W", CInt (image_size.x)); > image_dict.addProperty ("H", CInt (image_size.y)); > > Evidently, image_size.x and image_size.y are of type (const double), but they are passed to a constructor expecting an int&. I'm neither sure what is needed, nor sure what actually happens here (and that in itself is a minor problem). Given that we're dealing with references, however, I can't think of an approach the compiler could take to the issue that would be likely to have a satisfactory result. > > The most obvious fix would be to change the CInts to CReals, but I don't know whether that would cause trouble elsewhere in the program.CInt (static_cast<int>(image_size.x)) CInt (static_cast<int>(image_size.x)) and CInt (static_cast<int>(image_size.y)) ? Otherwise, you might need to change Tp to float or double (which seems like a lot more work). Since PDFs are widely abused as vectors (and it is CentOS), you might want to verify image_size.x and image_size.y are within bounds of the [integer] data type if you choose to cast. numeric_limits is your friend. Jeff |
From: Bollinger, J. C <John.Bollinger@STJUDE.ORG> - 2011-09-20 22:02:21
|
On Tuesday, September 20, 2011 4:35 PM, Jeffrey Walton wrote: > On Tue, Sep 20, 2011 at 5:13 PM, Bollinger, John C > <Joh...@st...> wrote: [...] > > The most obvious fix would be to change the CInts to CReals, but > I don't know whether that would cause trouble elsewhere in the > program.CInt (static_cast<int>(image_size.x)) > CInt (static_cast<int>(image_size.x)) and CInt > (static_cast<int>(image_size.y)) ? Otherwise, you might need to > change > Tp to float or double (which seems like a lot more work). > > Since PDFs are widely abused as vectors (and it is CentOS), you > might > want to verify image_size.x and image_size.y are within bounds of > the > [integer] data type if you choose to cast. numeric_limits is your > friend. Thanks, Jeff. Changing Tp to double is approximately the effect of switching the types from CInt to CReal. Only the lines I showed need to be modified, and the code then compiles fine without any more warnings in that section. The problem is that I'm not sure how to test adequately whether the resulting program works correctly. static_cast might do the job, but storing a reference to the result of a cast sounds dubious to me. It might work, but it seems like asking for trouble. Again, though, I'm not sure how to test the result adequately. Is there any clear guidance on what this ought to be, or is guess and test the best available approach? Thanks again, John Email Disclaimer: www.stjude.org/emaildisclaimer |
From: Jeffrey W. <nol...@gm...> - 2011-09-20 22:12:36
|
On Tue, Sep 20, 2011 at 6:02 PM, Bollinger, John C <Joh...@st...> wrote: > > On Tuesday, September 20, 2011 4:35 PM, Jeffrey Walton wrote: >> On Tue, Sep 20, 2011 at 5:13 PM, Bollinger, John C >> <Joh...@st...> wrote: > > [...] > >> > The most obvious fix would be to change the CInts to CReals, but >> I don't know whether that would cause trouble elsewhere in the >> program.CInt (static_cast<int>(image_size.x)) >> CInt (static_cast<int>(image_size.x)) and CInt >> (static_cast<int>(image_size.y)) ? Otherwise, you might need to >> change >> Tp to float or double (which seems like a lot more work). >> >> Since PDFs are widely abused as vectors (and it is CentOS), you >> might >> want to verify image_size.x and image_size.y are within bounds of >> the >> [integer] data type if you choose to cast. numeric_limits is your >> friend. > > Changing Tp to double is approximately the effect of switching the types from CInt to CReal. Only the lines I showed need to be modified, and the code then compiles fine without any more warnings in that section. The problem is that I'm not sure how to test adequately whether the resulting program works correctly. > > static_cast might do the job, but storing a reference to the result of a cast sounds dubious to me. It might work, but it seems like asking for trouble. OK. CInt should copy construct its object, so I don't believe its retaining an external reference. > Again, though, I'm not sure how to test the result adequately. > > Is there any clear guidance on what this ought to be, or is guess and test the best available approach? Take a look at CInt's data member declaration and see if its a reference. From http://pdfedit.cvs.sourceforge.net/viewvc/pdfedit/pdfedit/src/, I can't tell where it might be hiding. Also, if you can assign a CInt, I would expect that it does not hold an internal integer reference. As for the container that holds the name/value pair, they should be copy constructible. But I'm basing that on STL, and PDF Edit might be doing things differently. Jeff |
From: Michal H. <ms...@gm...> - 2011-09-21 08:19:18
|
On Tue, Sep 20, 2011 at 04:13:37PM -0500, Bollinger, John C wrote: > Hello All, Hi, > > As I wrote a few minutes ago, I am attempting to build PDFedit v 0.4.5 > on CentOS 5, using the distro's provided GCC 4.1.2 toolchain. Don't want to blame gcc here but 4.1.x was plain wrong. I would encourage you to use something newer. Anyway, > The method CPageContents::addInlineImage() is giving me some trouble, > the bulk of which I raised in my previous mail. In addition, however, > I see some worrisome warnings in the same method: > > g++ -c -g -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fexceptions -fstack-protector -pipe -posix -ansi -std=c++98 -pedantic -I. -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/ -I/usr/include -I/usr/include/freetype2 -I/usr/include -o cpagecontents.o cpagecontents.cc > cpagecontents.cc: In member function 'void pdfobjects::CPageContents::addInlineImage(const std::vector<char, std::allocator<char> >&, const libs::Point&, const libs::Point&)': > cpagecontents.cc:543: warning: passing 'const double' for argument 1 to 'pdfobjects::CObjectSimple<Tp>::CObjectSimple(const typename pdfobjects::PropertyTraitSimple<Tp>::value&) [with pdfobjects::PropertyType Tp = pInt]' > [...] > cpagecontents.cc:544: warning: passing 'const double' for argument 1 to 'pdfobjects::CObjectSimple<Tp>::CObjectSimple(const typename pdfobjects::PropertyTraitSimple<Tp>::value&) [with pdfobjects::PropertyType Tp = pInt]' > > These arise from the following two lines of code: > > image_dict.addProperty ("W", CInt (image_size.x)); > image_dict.addProperty ("H", CInt (image_size.y)); > > Evidently, image_size.x and image_size.y are of type (const double), > but they are passed to a constructor expecting an int&. I'm neither > sure what is needed, nor sure what actually happens here (and that in > itself is a minor problem). Given that we're dealing with references, > however, I can't think of an approach the compiler could take to the > issue that would be likely to have a satisfactory result. The warning is bogus. Pointer should just cast real to int (truncate it) and then provide a reference to a temporal int variable. > > The most obvious fix would be to change the CInts to CReals, but I > don't know whether that would cause trouble elsewhere in the program. PDF specification says that both Width and Height are integers so CInt is appropriate. > > > Best, > > John Bollinger > > > Email Disclaimer: www.stjude.org/emaildisclaimer > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Pdfedit-support mailing list > Pdf...@li... > https://lists.sourceforge.net/lists/listinfo/pdfedit-support -- Michal Hocko |
From: Bollinger, J. C <John.Bollinger@STJUDE.ORG> - 2011-09-21 14:50:29
|
On Wednesday, September 21, 2011 3:19 AM, Michal Hocko [mailto:ms...@gm...] wrote: > On Tue, Sep 20, 2011 at 04:13:37PM -0500, Bollinger, John C wrote: > > Hello All, > > Hi, > > > > > As I wrote a few minutes ago, I am attempting to build PDFedit v > 0.4.5 > > on CentOS 5, using the distro's provided GCC 4.1.2 toolchain. > > Don't want to blame gcc here but 4.1.x was plain wrong. I would > encourage you to use something newer. Well, I am in the process of upgrading to CentOS 6, which uses GCC 4.4. For the time being, however, I still need to support Cent5, which means I have to build (also) on Cent5. Even there, however, I guess there's a version of GCC 4.4 available, if only I can figure out how to get the build system to use it. It's probably not worth the effort, however. [...] > The warning is bogus. Pointer should just cast real to int > (truncate it) > and then provide a reference to a temporal int variable. Well, I wouldn't say the warning is bogus, but I'll accept that it is ignoreable in this situation. I guess a static_cast<int> would after all be the best way to make the warning go away, since it doesn't in the end matter that a temporal object is involved. > > > > The most obvious fix would be to change the CInts to CReals, but > I > > don't know whether that would cause trouble elsewhere in the > program. > > PDF specification says that both Width and Height are integers so > CInt > is appropriate. Fair enough. That's exactly the sort of answer I was looking for. Thanks, John Email Disclaimer: www.stjude.org/emaildisclaimer |
From: Jeffrey W. <nol...@gm...> - 2011-09-21 15:03:05
|
On Wed, Sep 21, 2011 at 10:50 AM, Bollinger, John C <Joh...@st...> wrote: > On Wednesday, September 21, 2011 3:19 AM, Michal Hocko [mailto:ms...@gm...] wrote: >> On Tue, Sep 20, 2011 at 04:13:37PM -0500, Bollinger, John C wrote: >> > As I wrote a few minutes ago, I am attempting to build PDFedit v >> 0.4.5 >> > on CentOS 5, using the distro's provided GCC 4.1.2 toolchain. >> >> Don't want to blame gcc here but 4.1.x was plain wrong. I would >> encourage you to use something newer. > > Well, I am in the process of upgrading to CentOS 6, which uses GCC 4.4. For the time being, however, I still need to support Cent5, which means I have to build (also) on Cent5. Even there, however, I guess there's a version of GCC 4.4 available, if only I can figure out how to get the build system to use it. It's probably not worth the effort, however. > > [...] > >> The warning is bogus. Pointer should just cast real to int >> (truncate it) >> and then provide a reference to a temporal int variable. > > Well, I wouldn't say the warning is bogus, but I'll accept that it is ignoreable in this situation. I guess a static_cast<int> would after all be the best way to make the warning go away, since it doesn't in the end matter that a temporal object is involved. Ah, a fellow clean-compile enthusiast (or security minded individual). Actually, we (I) treat a clean compile is a security gate. If the code can't clean compile, it does not meet quality standards and gets kicked until it can. You might want to to try -Wall -Wextra -Wformat=2 -Wformat-security -Woverloaded-virtual -Wreorder -Wno-unused -Wno-type-limits. The last three ease the use of C++ with -Wall -Wextra. For linker hardening, try -z relro and -z now for PLT and GOT attacks. Jeff |
From: Bollinger, J. C <John.Bollinger@STJUDE.ORG> - 2011-09-21 17:52:51
|
On Wednesday, September 21, 2011 10:03 AM, Jeffrey Walton [mailto:nol...@gm...] wrote: > On Wed, Sep 21, 2011 at 10:50 AM, Bollinger, John C > <Joh...@st...> wrote: [...] > > Well, I wouldn't say the warning is bogus, but I'll accept that > it is ignoreable in this situation. I guess a static_cast<int> > would after all be the best way to make the warning go away, since > it doesn't in the end matter that a temporal object is involved. > Ah, a fellow clean-compile enthusiast (or security minded > individual). Both, actually. I have been in the business quite long enough to appreciate the many ways C provides to unintentionally shoot yourself in the foot. Also long enough to recognize that C++ approximately squares the number of ways, plus arms you with a submachine gun with a flaky safety. Resolving warnings is like keeping the safety on, however much good that's going to do. > Actually, we (I) treat a clean compile is a security gate. If the > code > can't clean compile, it does not meet quality standards and gets > kicked until it can. > > You might want to to try -Wall -Wextra -Wformat=2 -Wformat-security > -Woverloaded-virtual -Wreorder -Wno-unused -Wno-type-limits. The > last > three ease the use of C++ with -Wall -Wextra. > > For linker hardening, try -z relro and -z now for PLT and GOT > attacks. Good advice, thanks. John Email Disclaimer: www.stjude.org/emaildisclaimer |