Piotr Stefaniak <postg...@piotr-stefaniak.me> writes: > Apart from what the page says, I also think of casting malloc() as bad > style and felt the need to bring this up.
Well, that's a value judgement I don't happen to agree with. Yeah, it'd be better if the language design were such that we could avoid explicit casting everywhere, but in this context casting is less risky than not casting. > So perhaps this alternative: > myextra = malloc(sizeof *myextra); [ shrug... ] That's about a wash for this exact use case, but it gets messy as soon as the lefthand side is anything more complicated than a simple variable name. And it doesn't scale to cases where the malloc result isn't directly assigned to anything --- for example, what if you want to pass the result of palloc() directly to some other function, or return it from the current function? The bigger picture though is that the style with the explicit cast is already extremely widely used in Postgres. That being the case, conforming to project style is better than using some inconsistent convention, regardless of your personal views about whether there's a better way to do it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers