Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: What is the value after operator '!'? Date: Tue, 27 Oct 2015 08:39:46 -0700 Organization: None to speak of Lines: 110 Message-ID: References: <7229ebda-7352-441e-9946-ccee1ce81b03@googlegroups.com> <87k2q9lp98.fsf@bsb.me.uk> <090eee37-7aeb-47e7-b195-ce3900b30fff@googlegroups.com> <87si4xjzui.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="21045"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18/c40lH6KQY6jw8DNsoQ8h" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Aph766hlioCdSGumORMwSuTWSxY= sha1:CwrWcjSGq09K0TgpkY/ZlMbTgiI= Xref: csiph.com comp.lang.c:73965 supercat@casperkitty.com writes: > On Monday, October 26, 2015 at 5:16:07 PM UTC-5, Keith Thompson wrote: >> supercat writes: >> > In a system where (char*)x would yield a pointer to physical address x, >> > and where physical address zero was valid, but where (char*)0 [i.e. NULL] >> > was represented by a pointer with some physical address other than zero, >> > would there be any way of writing a pointer constant equal to physical >> > address zero? >> >> No portable way -- but then pointer constants that refer to numeric >> addresses are inherently non-portable anyway. A compiler could provide >> some special-case way of representing address zero if it were useful. > > Many CPU architectures are used on a variety of hardware configurations, > and compilers are generally specialized per architecture, rather than > per hardware configuration. Obviously a program which is designed for > a system with various devices at different addresses will not be directly > portable to other CPU platforms, but it would be nice if it could be > reasonably portable among compilers for the same architecture. If you're willing to settle for "reasonably portable", just assume that a null pointer is all-bits-zero. Add a runtime check to the beginning of the program so the program dies if that's not the case. >> > I guess "1-1" wasn't sufficiently subtle for a compiler to miss that it was >> > really a constant; C# distinguishes between literal zeroes and integer >> > constants whose value happens to equal zero, but I guess C doesn't? >> >> Why guess? N1570 6.3.2.3 defines null pointer constants. 6.6 defines >> integer constant expressions. Read The Fine Manual. > > Sorry, by "I guess" I meant "I guess my memory of the distinctions among the > various C-ish languages isn't perfect". The rules for null pointer constants have not changed across C89/90, C99, and C11. (C++ rules differ, but not in any way that's relevant to the current discussion.) >> > Would the value of (int)0.3 be considered an integer constant? What about >> > (int)(1.0E+17+1.0-1.0E+17), whose value would depend upon how floating-point >> > precision was handled? >> >> N1570 6.6. Yes, it's possible to write an integer constant expression >> whose value is implementation-defined. (CHAR_BIT is another example of >> such an expression.) > > CHAR_BIT is a constant whose meaning can be known before a program begins > execution. The value yielded by adding 1 to 1E+17 and then subtracting > 1E17 from the result may vary depending upon the FPU configuration, and I > believe some compilers have options to defer floating-point calculations > until runtime for precisely that reason. (int)(1.0E+17+1.0-1.0E+17) is an integer constant expression. Its evaluation cannot be deferred until runtime, at least not if it's used in a context where a constant expression is required. Its value can vary depending on various factors. Has this ever been a problem for you? The only reason I can think of to use such an expression is because you *want* its value to depend on the system's floating-point characteristics. [...] >> > I wonder how much code would break if the Standard were to >> > require that the argument to the cast must have one of a small number of >> > literal forms (e.g. 0, 0L, etc.) rather than merely being any constant >> > expression whose value happens to be zero? >> >> I wonder how useful such a change would really be. If you want a >> pointer value whose representation is all-bits-zero, define a pointer >> object and call memset(). But I've never felt the need for such a >> pointer value. > > You probably have never coded for a machine that put anything useful at > address zero. No, I haven't. > One of the few places where the C Standard makes reference to the concept > of a target architecture being something apart from the implementation is > in the discussion of integer-to-pointer conversions, which are supposed to > be done in a fashion unsurprising to someone familiar with the architecture. > Having code work fine when configured to use the second parallel-I/O port > (whose address is set to 0x0002 in a header file) but then break when changed > to use the first (whose address is set to 0x0000) because the optimizer > ripped it to shreds would not satisfy the "unsurprising" requirement. If > the Standard provided that casting or coercing anything other than a single > digit zero directly to a pointer would invoke Implementation-Deined behavior, > and recommended that > > (char*)(intptr_t)0 > > should be interpreted according to the rules applicable to non-constant > expressions yielding zero, that shouldn't break much code (compilers could > include an option to interpret all forms of constant zero as the Standard > used to require) but also make it easier to avoid "surprises" when using > things that happen to use address zero. Leaving the definition as it is won't break *any* code. You propose changing the language definition to enable portable access to address 0 on systems where a null pointer is not represented as all-bits-zero. Do you have a real-world use case for this? If not, I suggest not worrying about it. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"