Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Sort char array Date: Mon, 14 Oct 2019 08:13:32 -0700 Organization: A noiseless patient Spider Lines: 25 Message-ID: <86mue3742r.fsf@linuxsc.com> References: <20191007174244.385138503569a8bc6d4eec9d@g{oogle}mail.com> <20191008022725.36fbd95aa45ba185290e5e11@gmail.com> <1q_mF.841756$Zy3.585129@fx33.am4> <20191009020207.b533aa1c6d95f44eb314ffc1@gmail.com> <5alnF.1041354$WI2.353384@fx34.am4> <5b525fc7-aeb6-47ec-b425-526a60d31e92@googlegroups.com> <20191013213244.ca6491d73d864b4226641958@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="d0509592842f78811f1490d2ec487131"; logging-data="32393"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18IA6h9Ok00clOWPPB8YfK9fKjr4q2Jjgs=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:LJtQ9akPXWdAhWM0ew9CQJdMQZo= sha1:Bv/yDGKm2KpHR8BfcZTiF21yQgE= Xref: csiph.com comp.lang.c:146952 Richard Damon writes: >> [getting C to have integer types of more than 64 bits] > > The issue is that there are many existing libraries (including those > provided by the OS), and changing the definition of an existing type > (like intmax_t) changes how those functions would be caused. To make > that change, and thus create a new incompatible ABI, says that to run a > program with that new ABI says that all the libraries that is uses > (including the OS calls) need to be provided in that new ABI. The OS > library in particular tends to be a bit slow in evolving, and the > existing solution, __int128_t being availble, but NOT considered an > extended integer type, so not considered by intmax_t, seems to work well > enough for practical uses, that the implementations and library > providers aren't rushing to make the change. > > The thing to remember is that supporting multiple ABIs adds complexity > to a system. That's true, but isn't it the case that many or most modern OSes support more than one ABI already (ie, 32-bit and 64-bit)? If they already support more than one, is it that much more work to add a third (or fourth, etc)? Of course the cost is non-zero, but I would think it would be a lot less than the cost of going from one to two, and that cost has already been paid.