TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Wuffs the Language

187 pointsby bshanksabout 4 years ago

12 comments

oconnor663about 4 years ago
&gt; There is no operator precedence. A bare a * b + c is an invalid expression. You must explicitly write either (a * b) + c or a * (b + c).<p>Honestly I&#x27;ve often wished for this in mainstream languages. It seems like operator precedence should go the way of bracketless if and implicit int casts. (Though I wonder if they wind up making exceptions here for chains of method calls? I guess technically those rely on operator precedence sort of?)<p>Edit: Yeah I see the example code has &quot;args.src.read_u8?()&quot;. So it looks like they figured out how to keep the good stuff.
评论 #26744752 未加载
评论 #26743783 未加载
评论 #26743831 未加载
评论 #26744055 未加载
评论 #26744590 未加载
评论 #26748825 未加载
评论 #26744149 未加载
评论 #26745798 未加载
评论 #26746515 未加载
dangabout 4 years ago
Surprisingly little discussed so far, aside from these past related threads:<p><i>Wuffs’ PNG image decoder</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26714831" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26714831</a> - April 2021 (135 comments)<p><i>C performance mystery: delete unused string constant</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23633583" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23633583</a> - June 2020 (105 comments)<p>That first one was just yesterday but this is a rare case where we would not downweight the follow-up post (<a href="https:&#x2F;&#x2F;hn.algolia.com&#x2F;?dateRange=all&amp;page=0&amp;prefix=true&amp;sort=byDate&amp;type=comment&amp;query=follow-up%20by%3Adang" rel="nofollow">https:&#x2F;&#x2F;hn.algolia.com&#x2F;?dateRange=all&amp;page=0&amp;prefix=true&amp;sor...</a>).
评论 #26743247 未加载
pnathanabout 4 years ago
This is a fascinating spin: a pure language, designed for <i>libraries</i>, not for complete programs. A tip of the hat to whoever was able to break out of the &quot;a language has to do x y and z&quot; thinking and perceive that this is a possibility.
评论 #26744271 未加载
评论 #26745195 未加载
评论 #26744506 未加载
评论 #26743503 未加载
peteretepabout 4 years ago
&gt; Traditionally, the first program anyone writes in a given programming language is something that prints &quot;Hello world&quot;. This doesn&#x27;t work for Wuffs, for two reasons. One is that Wuffs doesn&#x27;t have a string type per se. Two is that Wuffs code doesn&#x27;t even have the capability to write to files directly, such as to stdout. Wuffs is a language for writing libraries, not complete programs, and the less Wuffs can do, the less Wuffs can do that is surprising (such as upload your files to the internet), even when processing untrusted input.
grawprogabout 4 years ago
To be honest, I&#x27;m not sure what to make of this. Wuff the library makes sense as a drop in for the C standard library, but the language, I&#x27;m not sure how it fits.<p>It seems to offer some of the features offered by languages like D and Rust, while staying more C like, but also removing one of the few actual reasons to use C, which both D and Rust also provide on top of the other features offered by Wuff.<p>It&#x27;s cool and all but it seems confused as to whether it wants to be a library for C, an extension to C or a standalone language. As a stand alone language, I&#x27;m not sure I really see the benefits over alternatives as a C library, it does have some interesting ideas.
评论 #26743376 未加载
评论 #26743426 未加载
mjevansabout 4 years ago
The only part of the Wuffs spec I just read that I dislike:<p>Strings. I would really prefer strings to work like existing C and &#x27;bash&#x27; style quoting. At least the simple aspects of it, the parts of the rules that are easy to remember and simple. A string should always be a sequence of octets, but easily coerced by a casting operator to a numeric format from any index. I&#x27;m not sure what the syntax for that would be offhand.
评论 #26748671 未加载
评论 #26744667 未加载
incrudibleabout 4 years ago
I like the idea. The <i>inability</i> to do something is an often underrated feature.
ledauphinabout 4 years ago
I&#x27;m confused by the &quot;all functions are methods&quot; restriction. the &quot;what&quot; seems clear, but the &quot;why&quot; is eluding me, and I&#x27;d love to read an explanation.
mkjabout 4 years ago
How does error handling work in Wuffs? That seems to be an important aspect for a reliable language, it wasn&#x27;t immediately clear from the docs.<p>Edit ah found it, <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;wuffs&#x2F;blob&#x2F;main&#x2F;doc&#x2F;note&#x2F;statuses.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;wuffs&#x2F;blob&#x2F;main&#x2F;doc&#x2F;note&#x2F;statuses....</a>
peter_d_shermanabout 4 years ago
&gt;&quot;Wuffs (Wrangling Untrusted File Formats Safely) is formerly known as Puffs (Parsing Untrusted File Formats Safely). Wuffs is a memory-safe programming language (and a standard library written in that language) for wrangling untrusted file formats safely. Wrangling includes parsing, decoding and encoding. Example file formats include images, audio, video, fonts and compressed archives.<p>It is also fast. On many of its GIF decoding benchmarks, Wuffs measures 2x faster than &quot;giflib&quot; (C), 3x faster than &quot;image&#x2F;gif&quot; (Go) and 7x faster than &quot;gif&quot; (Rust).<p>Goals and Non-Goals<p>Wuffs&#x27; goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. This includes very large C&#x2F;C++ projects, such as popular web browsers and operating systems (using that term to include desktop and mobile user interfaces, not just the kernel).<p>Wuffs the Library is available as transpiled C code. Other C&#x2F;C++ projects can use that library without requiring the Wuffs the Language toolchain. Those projects can use Wuffs the Library like using any other third party C library. It&#x27;s just not hand-written C.<p>However, unlike hand-written C,<p><i>Wuffs the Language is safe with respect to buffer overflows, integer arithmetic overflows and null pointer dereferences.</i><p>A key difference between Wuffs and other memory-safe languages is that all such checks are done at compile time, not at run time. If it compiles, it is safe, with respect to those three bug classes.<p>The trade-off in aiming for both safety and speed is that Wuffs programs take longer for a programmer to write, as they have to explicitly annotate their programs with proofs of safety. A statement like x += 1 unsurprisingly means to increment the variable x by 1. However, in Wuffs, such a statement is a compile time error unless the compiler can also prove that x is not the maximal value of x&#x27;s type (e.g. x is not 255 if x is a base.u8), as the increment would otherwise overflow. Similarly, an integer arithmetic expression like x &#x2F; y is a compile time error unless the compiler can also prove that y is not zero.<p>Wuffs is not a general purpose programming language. It is for writing libraries, not programs. The idea isn&#x27;t to write your whole program in Wuffs, only the parts that are both performance-conscious and security-conscious. For example, while technically possible, it is unlikely that a Wuffs compiler would be worth writing entirely in Wuffs.&quot;<p>PDS: Would like to see a future AV1 &#x2F; AOM &#x2F; libaom &#x2F; FFmpeg -- written&#x2F;compiled in Wuffs...
chubotabout 4 years ago
Wuffs seems fascinating and I really wanted to like it. But when I look at the code for the JSON decoder it seems so low level, and full of places for bugs to hide. JSON is a pretty simple spec and this obscures it (although to be fair it&#x27;s also handling UTF-8).<p><a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;wuffs&#x2F;blob&#x2F;main&#x2F;std&#x2F;json&#x2F;decode_json.wuffs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;wuffs&#x2F;blob&#x2F;main&#x2F;std&#x2F;json&#x2F;decode_js...</a><p>Yes it prevents buffer overflows and integer overflow, but it can&#x27;t prevent logical errors.<p>I&#x27;d rather see efficient code generated from a short high level spec, not an overwhelming amount of detail in a language verified along a few dimensions.<p>---<p>Logical errors in parsing also lead to security vulnerabilities. For example, here is an example of parser differentials in HTTP parsing:<p><a href="https:&#x2F;&#x2F;about.gitlab.com&#x2F;blog&#x2F;2020&#x2F;03&#x2F;30&#x2F;how-to-exploit-parser-differentials&#x2F;" rel="nofollow">https:&#x2F;&#x2F;about.gitlab.com&#x2F;blog&#x2F;2020&#x2F;03&#x2F;30&#x2F;how-to-exploit-pars...</a><p>The canonical example of this class of bug is forging SSL certificates to take advantage of buggy parsers, but I don&#x27;t have a link handy. There should be one off of <a href="https:&#x2F;&#x2F;langsec.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;langsec.org&#x2F;</a> if anyone can help dig it up.<p>Again, this has nothing to do with buffer or integer overflows.<p>(aside: while googling for that I found the claim that mRNA vaccines work by parser differentials: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;maradydd&#x2F;status&#x2F;1342891437537505280?lang=en" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;maradydd&#x2F;status&#x2F;1342891437537505280?lang...</a> If anyone understands that I&#x27;d be curious on an opinion&#x2F;analysis :) )<p>At the very least, any language for parsing should include support for regular languages (regexes). The RFCs for many network protocols use this metalanguage, and there&#x27;s no reason it shouldn&#x27;t be executable. They compile easily to efficient code.<p>The VPRI project claimed to generate a TCP&#x2F;IP implementation from 200 lines of code, although it&#x27;s not really a fair comparison because it hasn&#x27;t been tested in the wild: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=846028" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=846028</a> .<p>Still I think that style has better engineering properties. Oil&#x27;s lexer, which understands essentially all of bash, is generated from a short source file<p><a href="https:&#x2F;&#x2F;www.oilshell.org&#x2F;release&#x2F;0.8.8&#x2F;source-code.wwz&#x2F;frontend&#x2F;lexer_def.py" rel="nofollow">https:&#x2F;&#x2F;www.oilshell.org&#x2F;release&#x2F;0.8.8&#x2F;source-code.wwz&#x2F;front...</a><p>which generates<p><a href="https:&#x2F;&#x2F;www.oilshell.org&#x2F;release&#x2F;0.8.8&#x2F;source-code.wwz&#x2F;_devbuild&#x2F;tmp&#x2F;osh-lex.re2c.h" rel="nofollow">https:&#x2F;&#x2F;www.oilshell.org&#x2F;release&#x2F;0.8.8&#x2F;source-code.wwz&#x2F;_devb...</a><p>which goes on to generate 28,000 lines of C code. It&#x27;s short, but it really needs a better regex metalanguage to be readable: <a href="https:&#x2F;&#x2F;www.oilshell.org&#x2F;release&#x2F;latest&#x2F;doc&#x2F;eggex.html" rel="nofollow">https:&#x2F;&#x2F;www.oilshell.org&#x2F;release&#x2F;latest&#x2F;doc&#x2F;eggex.html</a><p>A large part of JSON can be described by regular languages, and same with HTTP, etc.<p>-----<p>edit: An re2c target for wuffs could make sense. The generated code already doesn&#x27;t allocate any memory, although it uses tons of pointers which could be dangling.<p>And in fact that was a problem Cloudflare, which sprayed the user data of their customers all over the Internet back in 2017: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Cloudbleed" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Cloudbleed</a><p>That was with Ragel and not re2c, which perhaps has a more error prone API.
评论 #26744088 未加载
评论 #26744525 未加载
评论 #26748410 未加载
lancepiochabout 4 years ago
So a similar sense to Haxe: <a href="https:&#x2F;&#x2F;haxe.org" rel="nofollow">https:&#x2F;&#x2F;haxe.org</a>
评论 #26745425 未加载