Re: Use of C99 int types

From: Al Viro (viro_at_parcelfarce.linux.theplanet.co.uk)
Date: 04/04/05

  • Next message: Steven Rostedt: "Re: sched /HT processor"
    Date:	Mon, 4 Apr 2005 00:05:51 +0100
    To: Dag Arne Osvik <da@osvik.no>
    
    

    On Mon, Apr 04, 2005 at 12:48:04AM +0200, Dag Arne Osvik wrote:
    > unsigned long happens to coincide with uint_fast32_t for x86 and x86-64,
    > but there's no guarantee that it will on other architectures. And, at
    > least in theory, long may even provide less than 32 bits.

    To port on such platform we'd have to do a lot of rewriting - so much that
    the impact of this issue will be lost in noise.

    Look, it's very simple:
            * too many people blindly assume that all world is 32bit l-e.
            * too many of those who try to do portable code have very little
    idea of what that means - see the drivers that try and mix e.g. size_t with
    int, etc.
            * stdint is not widely understood, to put it mildly.
            * ...fast... types have very unfortunate names - these are guaranteed
    to create a lot of confusion.
            * pretty much everything in the kernel assumes that
    4 = sizeof(int) <=
    sizeof(long) = sizeof(pointer) = sizeof(size_t) = sizeof(ptrdiff_t) <=
    sizeof(long long) = 8
    and any platform that doesn't satisfy the above will require very serious
    work on porting anyway.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Steven Rostedt: "Re: sched /HT processor"

    Relevant Pages

    • Re: Excel-based Front End Reporting Tool
      ... the architectures handle this differently. ... > Microsoft Analysis Services based management information solution at my ... > There is no reason to be on any other platform other than an Microsoft ...
      (microsoft.public.sqlserver.olap)
    • Re: Angband with an accent: displaying extended characters
      ... I'd certainly expect a port to be possible, ... >> About platform stuff, the ideal situation would be if all platform dependent ... >> We are at least not in a hurry to remove support for RISCOS, ... future and which ones are lost cases that none care or compile for anymore. ...
      (rec.games.roguelike.angband)
    • Re: OpenVMS Itanium port progressing well says Gorham!
      ... do with the actual port itself. ... This was the BS spouted about OpenVMS when it apparently ... >>have been asking for a port to a low cost commodity platform ... >>100,000 for a 4 way server is commodity pricing. ...
      (comp.os.vms)
    • Re: Apple ahead of schedule
      ... They would find that preferable to making a port? ... platform or porting their product. ... efforts in the future to Windows, ...
      (comp.sys.mac.advocacy)
    • Re: Intel prepares to kill off the Pentium 4
      ... Roughly thirty-five million lines of OpenVMS source code and various and correspondingly giant build and test procedures, multiple languages, object code generation for x86-64, memory management for x86-64, linking for x86-64, signal handling, dealing with ACPI differences, dealing with I/O devices and interfaces, multiple third-party products. ... Be done with the port by lunchtime. ... The next step past this discussion: who would buy this OpenVMS x86-64 port, ... will Intel/Amd at one point start to "enforce" UEFI for the X86 platform? ...
      (comp.os.vms)