Re: quad_t and portability
On Fri, 06 Aug 1999 15:29:25 +0200, Sheldon Hearn wrote: > I want to patch wc(1) so that it uses quad_t instead of u_long. This is > necessary if wc(1) is to produce sensible results for files containing > more than 4GB of data. Yes yes, before you jump on my head, I meant u_quad_t. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: quad_t and portability
What is the approved method for getting ahold of 64 clean bits? I've been using the GNU/c9x "unsigned long long" and #ifdef-ing all over the place but this strikes me as substantially less than elegant. Once we have the bits, what is the Right Way to get them into network order? > -Original Message- > From: Sheldon Hearn [SMTP:sheld...@uunet.co.za] > Sent: Friday, August 06, 1999 8:34 AM > To: freebsd-hackers@freebsd.org > Subject: Re: quad_t and portability > > > > On Fri, 06 Aug 1999 15:29:25 +0200, Sheldon Hearn wrote: > > > I want to patch wc(1) so that it uses quad_t instead of u_long. This is > > necessary if wc(1) is to produce sensible results for files containing > > more than 4GB of data. > > Yes yes, before you jump on my head, I meant u_quad_t. :-) > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Aug 6, 3:29pm, Sheldon Hearn wrote: } Subject: quad_t and portability } } Hi folks, } } I want to patch wc(1) so that it uses quad_t instead of u_long. This is } necessary if wc(1) is to produce sensible results for files containing } more than 4GB of data. Why not off_t, which should be portable and scale properly with the maximum system file size. Then the only problem is figuring a portable means of printing the result ... To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Fri, 6 Aug 1999, Don Lewis wrote: > On Aug 6, 3:29pm, Sheldon Hearn wrote: > } Subject: quad_t and portability > } > } Hi folks, > } > } I want to patch wc(1) so that it uses quad_t instead of u_long. This is > } necessary if wc(1) is to produce sensible results for files containing > } more than 4GB of data. > > Why not off_t, which should be portable and scale properly with the > maximum system file size. Then the only problem is figuring a portable > means of printing the result ... > You can always use off_t with "%qd", (int64_t)foo. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Fri, 6 Aug 1999, Don Lewis wrote: > Why not off_t, which should be portable and scale properly with the > maximum system file size. Then the only problem is figuring a portable > means of printing the result ... sizeof() perhaps? - alex To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In message "Brian F. Feldman" writes: : You can always use off_t with "%qd", (int64_t)foo. But that isn't portbale. %qd is a bsdism. %lld and %llu are the latest C standards way to say that. Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, 7 Aug 1999, Warner Losh wrote: > In message > "Brian F. Feldman" writes: > : You can always use off_t with "%qd", (int64_t)foo. > > But that isn't portbale. %qd is a bsdism. %lld and %llu are the > latest C standards way to say that. Sorry, kinda used to quad rather than long long. I'm pretty sure ll isn't yet supported by the kernel printf functions... > > Warner > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In message "Brian F. Feldman" writes: : Sorry, kinda used to quad rather than long long. I'm pretty sure ll : isn't yet supported by the kernel printf functions... You may be right about that. Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
> In message > "Brian F. Feldman" writes: > : You can always use off_t with "%qd", (int64_t)foo. > > But that isn't portbale. %qd is a bsdism. %lld and %llu are the > latest C standards way to say that. If you're that fixed on portability, "%lux%08ulx", (long)foo>>32, (long)foo is always a perfectly-portable option (or %lud%08ud", (unsigned long)foo / UL, (unsigned long)foo % UL if you insist on decimal output; you'll need to watch the signs if you want to use longs instead of unsigned longs, but it's only mariginally more complicated). I doubt that the cost of splitting foo into two would be significant considering that it is split up into digits inside printf() anyway (it might actually be faster on some architectures). l8r, patryk. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
"Brian F. Feldman" wrote: > On Fri, 6 Aug 1999, Don Lewis wrote: > > > On Aug 6, 3:29pm, Sheldon Hearn wrote: > > } Subject: quad_t and portability > > } > > } Hi folks, > > } > > } I want to patch wc(1) so that it uses quad_t instead of u_long. This is > > } necessary if wc(1) is to produce sensible results for files containing > > } more than 4GB of data. > > > > Why not off_t, which should be portable and scale properly with the > > maximum system file size. Then the only problem is figuring a portable > > means of printing the result ... > > > > You can always use off_t with "%qd", (int64_t)foo. But not on the Alpha... int64_t is a long there, and gcc complains unless you use %ld. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, Aug 07, 1999 at 05:38:48PM +0800, Peter Wemm wrote: > "Brian F. Feldman" wrote: > > On Fri, 6 Aug 1999, Don Lewis wrote: > > > > > On Aug 6, 3:29pm, Sheldon Hearn wrote: > > > } Subject: quad_t and portability > > > } > > > } Hi folks, > > > } > > > } I want to patch wc(1) so that it uses quad_t instead of u_long. This is > > > } necessary if wc(1) is to produce sensible results for files containing > > > } more than 4GB of data. > > > > > > Why not off_t, which should be portable and scale properly with the > > > maximum system file size. Then the only problem is figuring a portable > > > means of printing the result ... > > > > > > > You can always use off_t with "%qd", (int64_t)foo. > > But not on the Alpha... int64_t is a long there, and gcc complains unless > you use %ld. Mmm and long is 32Bit it seems. At least that would explain some of the warnings I got when setting MAXDSIZ to 128G on alpha. -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de Usergroupi...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In article
you
write:
>In message "Brian
>F. Feldman" writes:
>: You can always use off_t with "%qd", (int64_t)foo.
>
>But that isn't portbale. %qd is a bsdism. %lld and %llu are the
>latest C standards way to say that.
Still isn't portable. DEC Alphas use "%ld", and don't know about "%lld".
I've resorted to doing something like: printf("64-bit:"QF"\n"), where QF
is the appropriate specifier for the system. (%qd, %lld, %ld).
--
Jonathan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, 7 Aug 1999, Peter Wemm wrote: > "Brian F. Feldman" wrote: > > On Fri, 6 Aug 1999, Don Lewis wrote: > > > > > On Aug 6, 3:29pm, Sheldon Hearn wrote: > > > } Subject: quad_t and portability > > > } > > > } Hi folks, > > > } > > > } I want to patch wc(1) so that it uses quad_t instead of u_long. This is > > > } necessary if wc(1) is to produce sensible results for files containing > > > } more than 4GB of data. > > > > > > Why not off_t, which should be portable and scale properly with the > > > maximum system file size. Then the only problem is figuring a portable > > > means of printing the result ... > > > > > > > You can always use off_t with "%qd", (int64_t)foo. > > But not on the Alpha... int64_t is a long there, and gcc complains unless > you use %ld. And 'q' on the alpha is what exactly, then? > > Cheers, > -Peter > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, 7 Aug 1999, Bernd Walter wrote: > On Sat, Aug 07, 1999 at 05:38:48PM +0800, Peter Wemm wrote: > > "Brian F. Feldman" wrote: > > > On Fri, 6 Aug 1999, Don Lewis wrote: > > > > > > > On Aug 6, 3:29pm, Sheldon Hearn wrote: > > > > } Subject: quad_t and portability > > > > } > > > > } Hi folks, > > > > } > > > > } I want to patch wc(1) so that it uses quad_t instead of u_long. This > > > > is > > > > } necessary if wc(1) is to produce sensible results for files containing > > > > } more than 4GB of data. > > > > > > > > Why not off_t, which should be portable and scale properly with the > > > > maximum system file size. Then the only problem is figuring a portable > > > > means of printing the result ... > > > > > > > > > > You can always use off_t with "%qd", (int64_t)foo. > > > > But not on the Alpha... int64_t is a long there, and gcc complains unless > > you use %ld. > Mmm and long is 32Bit it seems. > At least that would explain some of the warnings I got when setting MAXDSIZ to > 128G on alpha. Long is 64bit, int is 32bit on the alpha. Use u_int64_t to specify the bitsize. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, 7 Aug 1999, Warner Losh wrote:
> In message
> "Brian F. Feldman" writes:
> : Sorry, kinda used to quad rather than long long. I'm pretty sure ll
> : isn't yet supported by the kernel printf functions...
>
> You may be right about that.
The simple solution to this, which I'd like to see, is:
--- subr_prf.c.orig Sat Aug 7 14:52:55 1999
+++ subr_prf.c Sat Aug 7 15:03:19 1999
@@ -599,7 +599,11 @@
base = 10;
goto number;
case 'l':
- lflag = 1;
+ if (lflag) {
+ lflag = 0;
+ qflag = 1;
+ } else
+ lflag = 1;
goto reswitch;
case 'o':
if (qflag)
And yes, a quadword is defined by us as being 64 bits, as a long long is
defined in C9X. So I don't see any kind of problem doing this as a
solution, period.
>
> Warner
>
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In article <19990807165202.a37...@cicely8.cicely.de>, Bernd Walter wrote: > On Sat, Aug 07, 1999 at 05:38:48PM +0800, Peter Wemm wrote: > > > > But not on the Alpha... int64_t is a long there, and gcc complains unless > > you use %ld. > Mmm and long is 32Bit it seems. No, longs are 64 bits on the Alpha. Ints are 32 bits, though. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, 7 Aug 1999, John Polstra wrote:
> In article <19990807165202.a37...@cicely8.cicely.de>,
> Bernd Walter wrote:
> > On Sat, Aug 07, 1999 at 05:38:48PM +0800, Peter Wemm wrote:
> > >
> > > But not on the Alpha... int64_t is a long there, and gcc complains unless
> > > you use %ld.
> > Mmm and long is 32Bit it seems.
>
> No, longs are 64 bits on the Alpha. Ints are 32 bits, though.
Let us now note that the new, portable, 90's way of printing something
cast to a 64-bit value is
printf("foo = %lld\n", (long long)foo);
This works in the kernel (4.0 now) and userland, so it would be the
proper way. Is there anyone who is specifically checking for long long
C9X-compliancy in the source tree (mainly libc)?
Anyway, it's not an issue what the size of a long/int is, for printing
a 64-bit value. That was my point, I'm sure of it!
>
> John
> --
> John Polstra j...@polstra.com
> John D. Polstra & Co., Inc.Seattle, Washington USA
> "No matter how cynical I get, I just can't keep up."-- Nora Ephron
>
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
"Brian F. Feldman" wrote: > >Is there anyone who is specifically checking for long long >C9X-compliancy in the source tree (mainly libc)? I started reviewing libc for C9X features in general -- a fair amount of work is required to update macros and typedefs in (plus the new ). Doing a thorough job is difficult because C9X is somewhat gratuitously incompatible with gnu C (e.g. the spelling of __complex__, zero-length arrays in structures, macro varargs, etc.) and gnu C doesn't yet support restrict. Tony. -- f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Mon, 9 Aug 1999, Tony Finch wrote:
> "Brian F. Feldman" wrote:
> >
> >Is there anyone who is specifically checking for long long
> >C9X-compliancy in the source tree (mainly libc)?
>
> I started reviewing libc for C9X features in general -- a fair amount
> of work is required to update macros and typedefs in
> (plus the new ).
Shall we work on it, then?
>
> Doing a thorough job is difficult because C9X is somewhat gratuitously
> incompatible with gnu C (e.g. the spelling of __complex__, zero-length
> arrays in structures, macro varargs, etc.) and gnu C doesn't yet
> support restrict.
But GNU has officially stated that they will fully support C9X, and
they've started already. For instance, int *a = ((int [4]){1,2,3,4});
should work now, according to the infopages. Eventually, I'd be certain
that GNU would rather be compliant with C9X than with GNU C.
>
> Tony.
> --
> f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix
>
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Fri, 06 Aug 1999 15:29:25 +0200, Sheldon Hearn wrote: > I want to patch wc(1) so that it uses quad_t instead of u_long. This is > necessary if wc(1) is to produce sensible results for files containing > more than 4GB of data. Yes yes, before you jump on my head, I meant u_quad_t. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: quad_t and portability
What is the approved method for getting ahold of 64 clean bits? I've been using the GNU/c9x "unsigned long long" and #ifdef-ing all over the place but this strikes me as substantially less than elegant. Once we have the bits, what is the Right Way to get them into network order? > -Original Message- > From: Sheldon Hearn [SMTP:[EMAIL PROTECTED]] > Sent: Friday, August 06, 1999 8:34 AM > To: [EMAIL PROTECTED] > Subject: Re: quad_t and portability > > > > On Fri, 06 Aug 1999 15:29:25 +0200, Sheldon Hearn wrote: > > > I want to patch wc(1) so that it uses quad_t instead of u_long. This is > > necessary if wc(1) is to produce sensible results for files containing > > more than 4GB of data. > > Yes yes, before you jump on my head, I meant u_quad_t. :-) > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Aug 6, 3:29pm, Sheldon Hearn wrote: } Subject: quad_t and portability } } Hi folks, } } I want to patch wc(1) so that it uses quad_t instead of u_long. This is } necessary if wc(1) is to produce sensible results for files containing } more than 4GB of data. Why not off_t, which should be portable and scale properly with the maximum system file size. Then the only problem is figuring a portable means of printing the result ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Fri, 6 Aug 1999, Don Lewis wrote: > On Aug 6, 3:29pm, Sheldon Hearn wrote: > } Subject: quad_t and portability > } > } Hi folks, > } > } I want to patch wc(1) so that it uses quad_t instead of u_long. This is > } necessary if wc(1) is to produce sensible results for files containing > } more than 4GB of data. > > Why not off_t, which should be portable and scale properly with the > maximum system file size. Then the only problem is figuring a portable > means of printing the result ... > You can always use off_t with "%qd", (int64_t)foo. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Fri, 6 Aug 1999, Don Lewis wrote: > Why not off_t, which should be portable and scale properly with the > maximum system file size. Then the only problem is figuring a portable > means of printing the result ... sizeof() perhaps? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In message <[EMAIL PROTECTED]> "Brian F. Feldman" writes: : You can always use off_t with "%qd", (int64_t)foo. But that isn't portbale. %qd is a bsdism. %lld and %llu are the latest C standards way to say that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, 7 Aug 1999, Warner Losh wrote: > In message <[EMAIL PROTECTED]> "Brian F. >Feldman" writes: > : You can always use off_t with "%qd", (int64_t)foo. > > But that isn't portbale. %qd is a bsdism. %lld and %llu are the > latest C standards way to say that. Sorry, kinda used to quad rather than long long. I'm pretty sure ll isn't yet supported by the kernel printf functions... > > Warner > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In message <[EMAIL PROTECTED]> "Brian F. Feldman" writes: : Sorry, kinda used to quad rather than long long. I'm pretty sure ll : isn't yet supported by the kernel printf functions... You may be right about that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
> In message <[EMAIL PROTECTED]> "Brian F. >Feldman" writes: > : You can always use off_t with "%qd", (int64_t)foo. > > But that isn't portbale. %qd is a bsdism. %lld and %llu are the > latest C standards way to say that. If you're that fixed on portability, "%lux%08ulx", (long)foo>>32, (long)foo is always a perfectly-portable option (or %lud%08ud", (unsigned long)foo / UL, (unsigned long)foo % UL if you insist on decimal output; you'll need to watch the signs if you want to use longs instead of unsigned longs, but it's only mariginally more complicated). I doubt that the cost of splitting foo into two would be significant considering that it is split up into digits inside printf() anyway (it might actually be faster on some architectures). l8r, patryk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
"Brian F. Feldman" wrote: > On Fri, 6 Aug 1999, Don Lewis wrote: > > > On Aug 6, 3:29pm, Sheldon Hearn wrote: > > } Subject: quad_t and portability > > } > > } Hi folks, > > } > > } I want to patch wc(1) so that it uses quad_t instead of u_long. This is > > } necessary if wc(1) is to produce sensible results for files containing > > } more than 4GB of data. > > > > Why not off_t, which should be portable and scale properly with the > > maximum system file size. Then the only problem is figuring a portable > > means of printing the result ... > > > > You can always use off_t with "%qd", (int64_t)foo. But not on the Alpha... int64_t is a long there, and gcc complains unless you use %ld. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, Aug 07, 1999 at 05:38:48PM +0800, Peter Wemm wrote: > "Brian F. Feldman" wrote: > > On Fri, 6 Aug 1999, Don Lewis wrote: > > > > > On Aug 6, 3:29pm, Sheldon Hearn wrote: > > > } Subject: quad_t and portability > > > } > > > } Hi folks, > > > } > > > } I want to patch wc(1) so that it uses quad_t instead of u_long. This is > > > } necessary if wc(1) is to produce sensible results for files containing > > > } more than 4GB of data. > > > > > > Why not off_t, which should be portable and scale properly with the > > > maximum system file size. Then the only problem is figuring a portable > > > means of printing the result ... > > > > > > > You can always use off_t with "%qd", (int64_t)foo. > > But not on the Alpha... int64_t is a long there, and gcc complains unless > you use %ld. Mmm and long is 32Bit it seems. At least that would explain some of the warnings I got when setting MAXDSIZ to 128G on alpha. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In article [EMAIL PROTECTED]> you
write:
>In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
>: You can always use off_t with "%qd", (int64_t)foo.
>
>But that isn't portbale. %qd is a bsdism. %lld and %llu are the
>latest C standards way to say that.
Still isn't portable. DEC Alphas use "%ld", and don't know about "%lld".
I've resorted to doing something like: printf("64-bit:"QF"\n"), where QF
is the appropriate specifier for the system. (%qd, %lld, %ld).
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, 7 Aug 1999, Peter Wemm wrote: > "Brian F. Feldman" wrote: > > On Fri, 6 Aug 1999, Don Lewis wrote: > > > > > On Aug 6, 3:29pm, Sheldon Hearn wrote: > > > } Subject: quad_t and portability > > > } > > > } Hi folks, > > > } > > > } I want to patch wc(1) so that it uses quad_t instead of u_long. This is > > > } necessary if wc(1) is to produce sensible results for files containing > > > } more than 4GB of data. > > > > > > Why not off_t, which should be portable and scale properly with the > > > maximum system file size. Then the only problem is figuring a portable > > > means of printing the result ... > > > > > > > You can always use off_t with "%qd", (int64_t)foo. > > But not on the Alpha... int64_t is a long there, and gcc complains unless > you use %ld. And 'q' on the alpha is what exactly, then? > > Cheers, > -Peter > > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, 7 Aug 1999, Bernd Walter wrote: > On Sat, Aug 07, 1999 at 05:38:48PM +0800, Peter Wemm wrote: > > "Brian F. Feldman" wrote: > > > On Fri, 6 Aug 1999, Don Lewis wrote: > > > > > > > On Aug 6, 3:29pm, Sheldon Hearn wrote: > > > > } Subject: quad_t and portability > > > > } > > > > } Hi folks, > > > > } > > > > } I want to patch wc(1) so that it uses quad_t instead of u_long. This is > > > > } necessary if wc(1) is to produce sensible results for files containing > > > > } more than 4GB of data. > > > > > > > > Why not off_t, which should be portable and scale properly with the > > > > maximum system file size. Then the only problem is figuring a portable > > > > means of printing the result ... > > > > > > > > > > You can always use off_t with "%qd", (int64_t)foo. > > > > But not on the Alpha... int64_t is a long there, and gcc complains unless > > you use %ld. > Mmm and long is 32Bit it seems. > At least that would explain some of the warnings I got when setting MAXDSIZ to > 128G on alpha. Long is 64bit, int is 32bit on the alpha. Use u_int64_t to specify the bitsize. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, 7 Aug 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> : Sorry, kinda used to quad rather than long long. I'm pretty sure ll
> : isn't yet supported by the kernel printf functions...
>
> You may be right about that.
The simple solution to this, which I'd like to see, is:
--- subr_prf.c.orig Sat Aug 7 14:52:55 1999
+++ subr_prf.c Sat Aug 7 15:03:19 1999
@@ -599,7 +599,11 @@
base = 10;
goto number;
case 'l':
- lflag = 1;
+ if (lflag) {
+ lflag = 0;
+ qflag = 1;
+ } else
+ lflag = 1;
goto reswitch;
case 'o':
if (qflag)
And yes, a quadword is defined by us as being 64 bits, as a long long is
defined in C9X. So I don't see any kind of problem doing this as a
solution, period.
>
> Warner
>
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
In article <[EMAIL PROTECTED]>, Bernd Walter <[EMAIL PROTECTED]> wrote: > On Sat, Aug 07, 1999 at 05:38:48PM +0800, Peter Wemm wrote: > > > > But not on the Alpha... int64_t is a long there, and gcc complains unless > > you use %ld. > Mmm and long is 32Bit it seems. No, longs are 64 bits on the Alpha. Ints are 32 bits, though. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Sat, 7 Aug 1999, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Bernd Walter <[EMAIL PROTECTED]> wrote:
> > On Sat, Aug 07, 1999 at 05:38:48PM +0800, Peter Wemm wrote:
> > >
> > > But not on the Alpha... int64_t is a long there, and gcc complains unless
> > > you use %ld.
> > Mmm and long is 32Bit it seems.
>
> No, longs are 64 bits on the Alpha. Ints are 32 bits, though.
Let us now note that the new, portable, 90's way of printing something
cast to a 64-bit value is
printf("foo = %lld\n", (long long)foo);
This works in the kernel (4.0 now) and userland, so it would be the
proper way. Is there anyone who is specifically checking for long long
C9X-compliancy in the source tree (mainly libc)?
Anyway, it's not an issue what the size of a long/int is, for printing
a 64-bit value. That was my point, I'm sure of it!
>
> John
> --
> John Polstra [EMAIL PROTECTED]
> John D. Polstra & Co., Inc.Seattle, Washington USA
> "No matter how cynical I get, I just can't keep up."-- Nora Ephron
>
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
"Brian F. Feldman" <[EMAIL PROTECTED]> wrote: > >Is there anyone who is specifically checking for long long >C9X-compliancy in the source tree (mainly libc)? I started reviewing libc for C9X features in general -- a fair amount of work is required to update macros and typedefs in (plus the new ). Doing a thorough job is difficult because C9X is somewhat gratuitously incompatible with gnu C (e.g. the spelling of __complex__, zero-length arrays in structures, macro varargs, etc.) and gnu C doesn't yet support restrict. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: quad_t and portability
On Mon, 9 Aug 1999, Tony Finch wrote:
> "Brian F. Feldman" <[EMAIL PROTECTED]> wrote:
> >
> >Is there anyone who is specifically checking for long long
> >C9X-compliancy in the source tree (mainly libc)?
>
> I started reviewing libc for C9X features in general -- a fair amount
> of work is required to update macros and typedefs in
> (plus the new ).
Shall we work on it, then?
>
> Doing a thorough job is difficult because C9X is somewhat gratuitously
> incompatible with gnu C (e.g. the spelling of __complex__, zero-length
> arrays in structures, macro varargs, etc.) and gnu C doesn't yet
> support restrict.
But GNU has officially stated that they will fully support C9X, and
they've started already. For instance, int *a = ((int [4]){1,2,3,4});
should work now, according to the infopages. Eventually, I'd be certain
that GNU would rather be compliant with C9X than with GNU C.
>
> Tony.
> --
> f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix
>
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
