Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Octal Date: Tue, 27 Dec 2016 16:38:38 -0800 Organization: None to speak of Lines: 66 Message-ID: References: <9f751874-98cf-4208-b809-9e6424600ac6@googlegroups.com> <5de6cdd0-6a36-40da-9bd6-4387d43c7947@googlegroups.com> <9cb7833a-8479-4e61-8398-690783c4d975@googlegroups.com> <20280aee-5f78-47fa-ae22-c7bc852e3efb@googlegroups.com> <26119487-8644-4352-82bc-f1f1b6d7bb30@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="eac9cc7ad54a0b680082b6004da4ef88"; logging-data="22601"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Rg0N9uy08kckVwUkWcljl" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:rVVjLa+ujIUo/qM/fT7+vZV/bxw= sha1:RMt7xYo+fc9EnsyqjqL9hR4b4Es= Xref: csiph.com comp.lang.c:100380 supercat@casperkitty.com writes: > On Tuesday, December 27, 2016 at 2:44:15 PM UTC-6, Keith Thompson wrote: >> supercat writes: >> You've shown one case of someone running into the issue. In that one >> case, did adding spaces actually cause line width problems, or is that >> just a theoretical issue? (If so, prepending "1+" rather than appending >> "+1" would have been a workaround. Taking the time to modify the >> constants, perhaps using a script, might have been even better.) > > I don't know that adding spaces would have caused line-width problems in > that particular case, but I've certainly had other cases where a need to > add extra spaces to tables would cause line-width issues. > >> > A simple way to address the issue would be to say that compilers may at >> > their option process 0x1E+1 as three tokens 0x1E + 1, or may issue a >> > diagnostic. There are already many situations where some compilers will >> > silently accept code for which others would issue a diagnostic (e.g. >> > >> > int q[256u*256u]; >> >> 256u*256u clearly doesn't require a diagnostic. Compilers are permitted >> to warn about anything they like. > > What is the value of 256u*256u on systems where UINT_MAX is 65535? Why > would a diagnostic not be required on all such systems? The value of 256u*256u on such a system is 0u. A diagnostic is required because a zero-length array is a constraint violation. A diagnostic is not required on systems with UINT_MAX > 65535 because on such systems no constraint is violated. This is irrelevant to the topic of this thread. Start a new thread and I might consider discussing it further. [...] >> Ok, so let's say the standard is updated to say that a conforming >> compiler may, but need not, treat 0x1E+1 as three tokens -- >> and if it does so it needn't warn about it. You happen to use >> that construct in your code, without being aware of the issue. >> Years later you port the code to another compiler that rejects it. >> But hey, at least you were *temporarily* able to save two whole >> columns in one line of your C source file. > > I would expect that compilers would quickly evolve to accept the new syntax > without complaint if allowed to do so. Perhaps there's some non-contrived > way of writing a scanner where it's easier to regard "E+" and "E-" as special > within any number, than to regard an "E" as special only when processing a > decimal literal, but I would think using single-character look-ahead would > be easier than using multi-character. > > Is there some reason you think compiler writers would want to stick with > extra complexity whose primary purpose is to produce syntax errors from code > which would otherwise be unambiguous, rather than remove the weird cases > from their scanner and replace them with something simpler? What "extra complexity"? Have you read section 6.4.8 of the standard, describing preprocessing numbers? Again, suppose such a change is made. How long do you think it would take before C programmers can reliably assume that 0x1E+1 will *always* be treated as 3 tokens? -- 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"