tag:blogger.com,1999:blog-10770855.post3114285557828140580..comments2024-03-28T03:20:57.393-04:00Comments on The Little Calculist: The C Typedef Parsing ProblemDave Hermanhttp://www.blogger.com/profile/00405190527081772997noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-10770855.post-22983379504596547902019-09-22T13:08:34.374-04:002019-09-22T13:08:34.374-04:00This comment has been removed by the author.Unknownhttps://www.blogger.com/profile/09841940256939748152noreply@blogger.comtag:blogger.com,1999:blog-10770855.post-42630016272917415012010-10-27T21:13:08.835-04:002010-10-27T21:13:08.835-04:00I found this post while trying to remind myself wh...I found this post while trying to remind myself what the deal is with this ambiguity in C's syntax.<br /><br />I think the C statement "a * b;" illustrates the problem well. This statement can be read as declaring 'b' as a pointer to an entity of type 'a', or it can be read as multiplying the values of the variables 'a' and 'b' (and discarding the result). It is impossible to tell which is meant without knowing whether 'a' names a variable or a type.<br /><br />Perhaps it can be shown that all such examples involve throwing away the result of a calculation in a trivial way... which might lead to a heuristic allowing sensible compilation in the absence of a type dictionary.<br /><br />Of course, C++ inherited the issue, and '*' above could then be overloaded and do all sorts of wacky stuff behind the scene...Sebastien Carliernoreply@blogger.comtag:blogger.com,1999:blog-10770855.post-46818605301265337742009-02-15T06:45:00.000-05:002009-02-15T06:45:00.000-05:00I'm curious as to why this came up for you.It's to...<I>I'm curious as to why this came up for you.</I><BR/><BR/>It's totally mundane, nothing research-related. I am building a tool for PLT Scheme that allows you to take a C header and compute binary layout information for the foreign function interface.Dave Hermanhttps://www.blogger.com/profile/00405190527081772997noreply@blogger.comtag:blogger.com,1999:blog-10770855.post-31810078891794585042009-02-15T04:44:00.000-05:002009-02-15T04:44:00.000-05:00Even in terms of lexing and parsing, I'd say that'...Even in terms of lexing and parsing, I'd say that's bad enough to be a performance bug: if you want to try to parallelize the process, this means you're forced to do wacko speculative tricks beyond the norm. Stepping back, however, unless variable identifiers and type identifiers can have different values, I'm not sure why one would advocate differentiating them within the lexer.<BR/><BR/><BR/>I'm curious as to why this came up for you :)lmeyerovhttps://www.blogger.com/profile/05895714526572076172noreply@blogger.comtag:blogger.com,1999:blog-10770855.post-50282884287078861112009-02-14T05:52:00.000-05:002009-02-14T05:52:00.000-05:00A good post.What a mess, though. These are the sor...A good post.<BR/><BR/>What a mess, though. These are the sorts of things about C syntax that just make my skin crawl. <BR/><BR/>Relatedly, I think C's attempt to make variable and function declaration "look like usage" to be a demented and failed experiment. It's a shame, really that a language where pointers are so central makes declaring types dereferencing those pointers syntactically so awkward. <BR/><BR/>I'll take:<BR/><BR/>type Handler = procedure(var m: array of Message): pointer to Result;<BR/><BR/>over<BR/><BR/>typedef Result *(*Handler)(message (*m)[]));<BR/><BR/>or whatevertheheck the correct mangling would be. In C is virtually impossible to even tell which identifier is being declared without playing parser. A declaration syntax that can't even manage that really is a failure.Unknownhttps://www.blogger.com/profile/10395072917390353102noreply@blogger.com