All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Stephan von Krawczynski <skraw@ithnet.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Typedefs / gcc / HIGHMEM
Date: Sat, 08 Dec 2001 16:41:56 -0800	[thread overview]
Message-ID: <3C12B354.3060801@zytor.com> (raw)
In-Reply-To: <200112090039.BAA25399@webserver.ithnet.com>

Stephan von Krawczynski wrote:

>>                                                                    
>>Why should there be?  The u32 value gets promoted to u64 before the 
>>comparison is done.                                                 
>>
>                                                                       
> Yes, ok, you're right. This was not a well thought out statement.     
> Anyway the problem with printf statement stays. It is obviously       
> confused by a unsigned long long and "%08x". How would you fix this?  
> Downcasting to u32?                                                   
> 


Either that or change it to %016llx or something like that.

>                                                                       
> Ha, I always wondered what this u64 is all about :-)                  
> Honestly, this whole datatyping is gone completely mad since the 16-32
> bit  change. In my opinion                                            
> byte is 8 bit                                                         
> short is 16 bit                                                       
> long is 32 bit                                                        
> <callwhatyouwant> is 64 bit (I propose long2 for expression of bitsize
> long * 2).                                                            
> <callwhatyouwant2> is 128 bit (Ha, right I would call it long4)       
>     


Well, you're wrong.

                                                                      
> How do you call a 64 bit datatype in a 128 bit environment? According 
> to your / the worlds current terminology long will then be 128 bit and
> int will (ridiculously) still be 32 bit. It will be pretty interesting
> to hear people talking about integer registers and people writing     
> portable applications do #define int long ... A wait this will break  
> your #typedef unsigned int u32 story :-)                              


int64_t.  See the C99 standard.

	-hpa


  reply	other threads:[~2001-12-09  0:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-08 18:38 Typedefs / gcc / HIGHMEM Stephan von Krawczynski
2001-12-08 23:40 ` H. Peter Anvin
2001-12-09  0:39   ` Stephan von Krawczynski
2001-12-09  0:41     ` H. Peter Anvin [this message]
2001-12-09  0:55       ` [MOc]cda*mirabilos
2001-12-09  1:09         ` H. Peter Anvin
2001-12-09  0:48     ` [MOc]cda*mirabilos
  -- strict thread matches above, loose matches on Subject: below --
2001-12-09  9:31 RaúlNúñez de Arenas Coronado

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C12B354.3060801@zytor.com \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=skraw@ithnet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.