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: is there a way to ask a variable what it is? Date: Sat, 22 Feb 2020 09:42:21 -0800 Organization: A noiseless patient Spider Lines: 42 Message-ID: <865zfycyde.fsf@linuxsc.com> References: <87zhe5pzqf.fsf@bsb.me.uk> <86lfozeswm.fsf@linuxsc.com> <75f1fb82-5e5d-40d5-88e6-a701c17d619f@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="a1e79922b2c02e9149a52088916eaff2"; logging-data="18359"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/T57Ub2ZQfE+36ihe92flnuSUDIgnExis=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:xCURjwoEywhdax1Y1jFUrtvbitA= sha1:1qmBkgzKyqqAZGXwSGrEzDyPT40= Xref: csiph.com comp.lang.c:150154 already5chosen@yahoo.com writes: > On Tuesday, February 18, 2020 at 6:56:18 PM UTC+2, Tim Rentsch wrote: > >> Ben Bacarisse writes: >> >>> [...] C is a statically typed language so all type information, >>> and everything easily derived from type information, is known at >>> compile time. >> >> I don't think that's right exactly. For one example, some type >> information may be known in one translation unit but not known >> in another. A declaration like >> >> extern int special_values[]; >> >> offers partial but not complete type information in this TU, and >> so is not known at compile time. > > What is "a real type", if there is such thing, is unknown, but > what compiler think about the type when it deals with this > specific translation unit is know. > >> A second example is variable length arrays. Here the type >> information is not known until run time, and usually is not fixed >> but varies with different invocations. > > Here we are at philosophical question of "what is considered a > type?". There are two meanings of "type" that come into play here. One meaning is the type of an identifier (or an expression). The second meaning is the type of an object, irrespective of the type of an expression used to designate the object. These two meanings are sometimes called "static type" and "dynamic type", respectively. Most of what I was pointing out is that the two need not be the same, even if in most situations they are. By the way I am sure that Ben Bacarisse knows all this. I see in a later response that his earlier posting was simplified for the benefit of who he was responding to, and I misunderstood the intended context of his statement. Sorry for the confusion.