Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Sort char array Date: Sun, 13 Oct 2019 13:30:17 -0700 Organization: None to speak of Lines: 65 Message-ID: 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> <20191010003208.ff29e87d2de1e17c50f96c74@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="3e80b707b7b018c85c895dc526a0ef31"; logging-data="2997"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+tTVrOTNiFzszS/xYc40+m" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:jWPAfraDnQ+2MCaBs5HjrMvPWpU= sha1:3KBu5j74piLXe0tTYh/8vCVFpXE= Xref: csiph.com comp.lang.c:146922 David Brown writes: [...] > I guess I don't really mean I want the types to be compatible - I mean > I want the result of casting from one pointer type to another to work > as though the types were compatible. (And in case it was missed, I am > only talking here about types where the size and representations are > the same.) I am not quite sure of the best term to describe it, nor > the best way to achieve it. It sounds like you want to loosen the effective type rules (6.5p6-7) so that an object whose effective type is an integer type can be accessed by an lvalue of another integer type that has the same representation, alignment, and perhaps some other characteristics. (I suppose the same would apply to floating-point types, for example for implementations where double and long double have the same representation.) The types would still be incompatible, and pointer casts would still be needed. Such a change would inhibit some optimizations. For example: long x = 42; long long ptr = ...; /* a bunch of code that doesn't refer to x */ if (x == 42) { /* ... */ } Currently a compiler can assume that x has not been modified via ptr. I'm not sure whether such a change would be worth that cost. [...] > My main aim here is that there should be a standardised way to be sure > about that assumption. I'm not sure what that would look like, but ok. One possibility might be something like a C++-style cast, a conversion operator that would convert the pointer types but would be a constraint volation if the target types differ in representation. I don't think it's likely such a feature would be added without a lot more thought than I've put into it. [...] > I don't think my suggestion is as bad as it appeared to you, since I > would want the code to fail to compile when it would not work as > expected. My objection is that, given your previous suggestion, assigning a long* value to a long long* object would not be required to give a warning if long and long long happen to have the same representation *on the current system*. It would encourage non-portable code. In C as it's currently defined, types can be distinct and incompatible even if they happen to have the same representation. I see this as a good thing. What's missing is a way to define new and distinct integer types. (And adding a way to do that could break a lot of uses of _Generic.) [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */