Date: Sat, 29 Dec 2012 20:10:01 GMT From: Robin Carey <robin.carey1@googlemail.com> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/174549: UINT64_MAX missing in C++ Program Message-ID: <201212292010.qBTKA1bu030319@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/174549; it has been noted by GNATS. From: Robin Carey <robin.carey1@googlemail.com> To: bf1783@gmail.com, bug-followup@freebsd.org Cc: Subject: Re: misc/174549: UINT64_MAX missing in C++ Program Date: Sat, 29 Dec 2012 20:03:54 +0000 --089e0122a8969c795b04d2034783 Content-Type: multipart/alternative; boundary=089e0122a8969c795804d2034781 --089e0122a8969c795804d2034781 Content-Type: text/plain; charset=ISO-8859-1 Dear Brendan & bug-followup, Re: Bug: misc/174549 I have discovered what was causing the problem. I am not sure if this is a bug or not since it relates to the double-inclusion of <stdint.h>. To reproduce the bug, download "cp2.tgz" (tar archive; gzipped): http://www.leopard.uk.com/CP Then apply the attached diffs (to 2 files; Counter128.h and test.cxx). The commands used to generate the diff files are, i.e. "diff test.cxx test.cxx.ORIG" and "diff Counter128.h Counter128.h.ORIG". You will then find that the following command fails with previously reported error: "g++ -Wall test.cxx -lcrypto" ------- The only reason I discovered what was causing the problem was because I just recently released Version 2 of my Cipher-Packet software (and in the process of doing that cleaned up "test.cxx" and removed the redundant <stdint.h> inclusion that was in there from previous coding/testing/etc). Sorry if I have wasted anybodys time. On 29 December 2012 15:37, b.f. <bf1783@googlemail.com> wrote: > On 12/29/12, Robin Carey <robin.carey1@googlemail.com> wrote: > > Dear b.f., > > > > Before I potentially waste any more of my time: > > > > Are you a FreeBSD developer ? > > > > What is your name ? > > You mean before you spend any more of your time? I'd hardly say that > we've completely wasted our time, although we haven't yet resolved > your problem. Sometimes these things take some time and patience to > track down, and it's important to provide detailed information about > the nature of the error. > > My name is Brendan, and I am a FreeBSD Ports committer > (bf@FreeBSD.org). Usually I just go by my initials on the FreeBSD > lists, but you may also use my name if you wish. For the purposes of > this PR, of course, all this doesn't really matter, as anyone can > respond in the PR audit trail, regardless of whether they are the one > who takes ownership of the PR and commits a fix, if this should shown > to be necessary. > > I tried again to reproduce your problem, this time starting with your > cp2.tgz, and using 10-CURRENT (r240150) i386. Using c++ (gcc 4.2.x), > the unmodified test.cxx failed to compile with the usual error ( ... > UINT64_MAX was not declared in this scope ... ). But by using either > -D__STDC_LIMIT_MACROS, or by uncommenting the analogous #define in > your Counter128.h, the program compiled successfully, as expected -- > there was no apparent difference between these two approaches. I took > a quick look at the diff between the i386 system headers in 9.1 and > r240150, and I didn't notice anything that might result in a different > outcome on 9.1. But as an extra check, I extracted the 9.1 i386 > system headers from the 9.1 release > tarballs( > http://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.1-RELEASE/base.txz > ) > into a local directory (/tmp/9.1), and attempted to compile the > program against them on -CURRENT using "c++ -isysroot /tmp/9.1 ....". > There was no change in the above outcomes with the 9.1 i386 headers. > So I have not encountered the error that you reported in your last few > messages, in which the #define __STDC_LIMIT_MACROS failed to work when > placed before the inclusion of <stdint.h>. If you'd like to submit > the preprocessor output for a file that results in such an error, > together with those file(s) or a diff of those file(s) against the > unmodified file(s) in cp2.tgz, I'm willing to take a look. You should > at least send it to the audit trail of the PR, via > bug-followup@FreeBSD.org. Whether or not you think my input will be > useful, I think that you will have to submit such information in order > for anyone to try to diagnose your problem. > > Regards, > b. > -- Sincerely, Robin Carey BSc --089e0122a8969c795804d2034781 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Dear Brendan & bug-followup,</div><div>=A0</div><div>Re: Bug: misc= /174549</div><div>=A0</div><div>I have discovered what was causing the prob= lem.</div><div>I am not sure if this is a bug or not since it relates to th= e double-inclusion of <stdint.h>.</div> <div>=A0</div><div>To reproduce the bug, download "cp2.tgz" (tar = archive; gzipped):</div><div>=A0</div><div><a href=3D"http://www.leopard.uk= .com/CP">http://www.leopard.uk.com/CP</a></div><div>=A0</div><div>Then appl= y the attached diffs (to 2 files; Counter128.h and test.cxx). The commands = used to generate</div> <div>the diff files are, i.e. "diff test.cxx test.cxx.ORIG" and &= quot;diff Counter128.h Counter128.h.ORIG".</div><div>=A0</div><div>You= will then find that the following command fails with previously reported e= rror:</div> <div>=A0</div><div>"g++ -Wall test.cxx -lcrypto"</div><div>=A0</d= iv><div>-------</div><div>=A0</div><div>The only reason I discovered what w= as causing the problem was because I just recently</div><div>released Versi= on 2 of my Cipher-Packet software (and in the process of doing that</div> <div>cleaned up "test.cxx" and removed the redundant <stdint.h= > inclusion that was in there from</div><div>previous coding/testing/etc= ).</div><div>=A0</div><div>Sorry if I have wasted anybodys time.<br><br></d= iv> <div class=3D"gmail_quote">On 29 December 2012 15:37, b.f. <span dir=3D"ltr= "><<a href=3D"mailto:bf1783@googlemail.com" target=3D"_blank">bf1783@goo= glemail.com</a>></span> wrote:<br><blockquote style=3D"margin:0px 0px 0p= x 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wid= th:1px;border-left-style:solid" class=3D"gmail_quote"> <div class=3D"im">On 12/29/12, Robin Carey <<a href=3D"mailto:robin.care= y1@googlemail.com">robin.carey1@googlemail.com</a>> wrote:<br> > Dear b.f.,<br> ><br> > Before I potentially waste any more of my time:<br> ><br> > Are you a FreeBSD developer ?<br> ><br> > What is your name ?<br> <br> </div>You mean before you spend any more of your time? =A0I'd hardly sa= y that<br> we've completely wasted our time, although we haven't yet resolved<= br> your problem. =A0Sometimes these things take some time and patience to<br> track down, and it's important to provide detailed information about<br= > the nature of the error.<br> <br> My name is Brendan, and I am a FreeBSD Ports committer<br> (bf@FreeBSD.org). =A0Usually I just go by my initials on the FreeBSD<br> lists, but you may also use my name if you wish. =A0For the purposes of<br> this PR, of course, all this doesn't really matter, as anyone can<br> respond in the PR audit trail, regardless of whether they are the one<br> who takes ownership of the PR and commits a fix, if this should shown<br> to be necessary.<br> <br> I tried again to reproduce your problem, this time starting with your<br> cp2.tgz, and using 10-CURRENT (r240150) i386. =A0Using c++ (gcc 4.2.x),<br> the unmodified test.cxx failed to compile with the usual error ( ...<br> UINT64_MAX was not declared in this scope ... ). =A0But by using either<br> -D__STDC_LIMIT_MACROS, or by uncommenting the analogous #define in<br> your Counter128.h, the program compiled successfully, as expected --<br> there was no apparent difference between these two approaches. =A0I took<br= > a quick look at the diff between the i386 system headers in 9.1 and<br> r240150, and I didn't notice anything that might result in a different<= br> outcome on 9.1. =A0But as an extra check, I extracted the 9.1 i386<br> system headers from the 9.1 release<br> tarballs(<a href=3D"http://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9= .1-RELEASE/base.txz" target=3D"_blank">http://ftp.freebsd.org/pub/FreeBSD/r= eleases/i386/i386/9.1-RELEASE/base.txz</a>)<br> into a local directory (/tmp/9.1), and attempted to compile the<br> program against them on -CURRENT using "c++ -isysroot /tmp/9.1 ....&qu= ot;.<br> There was no change in the above outcomes with the 9.1 i386 headers.<br> So I have not encountered the error that you reported in your last few<br> messages, in which the #define __STDC_LIMIT_MACROS failed to work when<br> placed before the inclusion of <stdint.h>. =A0If you'd like to su= bmit<br> the preprocessor output for a file that results in such an error,<br> together with those file(s) or a diff of those file(s) against the<br> unmodified file(s) in cp2.tgz, I'm willing to take a look. =A0You shoul= d<br> at least send it to the audit trail of the PR, via<br> bug-followup@FreeBSD.org. Whether or not you think my input will be<br> useful, I think that you will have to submit such information in order<br> for anyone to try to diagnose your problem.<br> <br> Regards,<br> b.<br> </blockquote></div><br><br clear=3D"all"><br>-- <br><div>Sincerely,</div><d= iv><br>Robin Carey BSc</div> --089e0122a8969c795804d2034781-- --089e0122a8969c795b04d2034783 Content-Type: application/octet-stream; name="test.cxx.diff" Content-Disposition: attachment; filename="test.cxx.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hbb6dgsj0 MmQxCjwgIyBpbmNsdWRlICA8c3RkaW50Lmg+Cg== --089e0122a8969c795b04d2034783 Content-Type: application/octet-stream; name="Counter128.h.diff" Content-Disposition: attachment; filename="Counter128.h.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hbb6dpxi1 NDJjNDIKPCAjIGRlZmluZSAgX19TVERDX0xJTUlUX01BQ1JPUwotLS0KPiAvLyMgZGVmaW5lICBf X1NURENfTElNSVRfTUFDUk9TCg== --089e0122a8969c795b04d2034783--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201212292010.qBTKA1bu030319>