From owner-freebsd-bugs@FreeBSD.ORG Sat Dec 29 20:10:02 2012 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BAC44C6 for ; Sat, 29 Dec 2012 20:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF408FC0C for ; Sat, 29 Dec 2012 20:10:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBTKA1Vf030320 for ; Sat, 29 Dec 2012 20:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBTKA1bu030319; Sat, 29 Dec 2012 20:10:01 GMT (envelope-from gnats) Date: Sat, 29 Dec 2012 20:10:01 GMT Message-Id: <201212292010.qBTKA1bu030319@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Robin Carey Subject: Re: misc/174549: UINT64_MAX missing in C++ Program X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Robin Carey List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 20:10:02 -0000 The following reply was made to PR misc/174549; it has been noted by GNATS. From: Robin Carey 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 . 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 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. wrote: > On 12/29/12, Robin Carey 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 . 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
Dear Brendan & bug-followup,
=A0
Re: Bug: misc= /174549
=A0
I have discovered what was causing the prob= lem.
I am not sure if this is a bug or not since it relates to th= e double-inclusion of <stdint.h>.
=A0
To reproduce the bug, download "cp2.tgz" (tar = archive; gzipped):
=A0
=A0
Then appl= y 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 &= quot;diff Counter128.h Counter128.h.ORIG".
=A0
You= will then find that the following command fails with previously reported e= rror:
=A0
"g++ -Wall test.cxx -lcrypto"
=A0
-------
=A0
The only reason I discovered what w= as causing the problem was because I just recently
released Versi= on 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= ).
=A0
Sorry if I have wasted anybodys time.

On 29 December 2012 15:37, b.f. <bf1783@goo= glemail.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? =A0I'd hardly sa= y that
we've completely wasted our time, although we haven't yet resolved<= br> your problem. =A0Sometimes 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). =A0Usually I just go by my initials on the FreeBSD
lists, but you may also use my name if you wish. =A0For 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. =A0Using c++ (gcc 4.2.x),
the unmodified test.cxx failed to compile with the usual error ( ...
UINT64_MAX was not declared in this scope ... ). =A0But 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. =A0I 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<= br> outcome on 9.1. =A0But as an extra check, I extracted the 9.1 i386
system headers from the 9.1 release
tarballs(http://ftp.freebsd.org/pub/FreeBSD/r= eleases/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 ....&qu= ot;.
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>. =A0If you'd like to su= bmit
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. =A0You shoul= d
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-- --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--