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: A glitch regarding the usual malloc() idiom Date: Fri, 22 Jul 2016 11:05:56 -0700 Organization: None to speak of Lines: 79 Message-ID: References: <0def6c1e-9b42-43d9-9280-393dfc0f6bf4@googlegroups.com> <87de1c4a-56ce-4840-8567-f7c55d12384a@googlegroups.com> <52247664-de2e-44ae-b1c3-8fc2b702df48@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="14618"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+wSIGUym3KTpzelBIHY0da" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:kNlvmyMR94EB4vmjR0kF8Lwve/U= sha1:JrHvXpFddBpswiFQXRu5y6gErHw= Xref: csiph.com comp.lang.c:90799 BartC writes: > On 22/07/2016 17:17, Keith Thompson wrote: >> BartC writes: >>> There are a lot of inconsistencies associated with this trivial little >>> feature. >> >> No. > > Here's a little list of minor issues to do with sizeof in C, and how > they compare with the equivalent in my own language: Ah, so you consider any special-case rule to be an "inconsistency". Special-case rules make the description a bit more complicated than it would otherwise be, but the description as a whole is still logically consistent. > C My lang > > (1) Special rule about parentheses yes no sizeof, like any other unary operator (quibble: it's not syntactically a "unary-operator", but it plays a very similar role) takes an expression as its operand. The special rule is that the operand can also be a parenthesized type name. > (2) Special treatment for array types yes no Yes, there's a special rule when the argument is an expression of array type. Similar special rules apply when an expression of array type is the operand of unary "&" and when it's a string literal in an initializer used to initialize an array object. > (3) Can look like an operator yes no Yes, because it is an operator. > (4) Can look like a function yes no Not really, because function names are never keywords -- and if the operand is an expression and you don't add redundant parentheses, it *doesn't* look like a function call. Similarly, a return statement can look like a function call if you add redundant parentheses. An if or while statement can look look like a function call if you use the same spacing. > (5) sizeof * p has same shape as a * b yes no Easily avoided with judicious use of whitespace. Never write `sizeof * p` (unless you're being deliberately obscure). If you insist on writing `sizeof (*p)`, you're perfectly free to do so. > (6) Special rule: expr can't start with cast yes no Needed because of the syntactic similarity of a parenthesized type name used as a cast operator and a parenthesized type name used as the operand of sizeof. But why would you apply sizeof to a cast expression? If you're specifying the type, you don't need a cast; just use the type name by itself. Has this *ever* been a problem for you? If you do need to apply sizeof to a cast expression for some reason (perhaps it's being invoked via a macro?), just add parentheses. > (7) *p expression not evaluated yes yes > (8) Something funny about VLAs yes n.a. [...] > That's why I said there are a lot of inconsistencies. There are a number of special-case rules (though fewer than you claim), but the entire set of rules, special cases included, is consistent. -- 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"