TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Bugs in Hello World

527 点作者 sizediterable大约 3 年前

49 条评论

HellsMaddy大约 3 年前
You all joke that this doesn’t happen in practice, but something like this literally just bit me and it took me a few too many minutes to figure out what was going on.<p>I use a bash script as my BROWSER which calls another bash script to launch or communicate with my browser that I run inside a container. The script that my BROWSER script calls has some debug output that it prints to stderr.<p>I use mutt as my email client and urlscan [0] to open URLs inside emails. Urlscan looks at my BROWSER environment variable and thus calls my script to open whatever URL I target. Some time recently, the urlscan author decided to improve the UX by hiding stderr so that it wouldn’t pollute the view, and so attempted to pipe it to `&#x2F;dev&#x2F;null`. I guess their original code to do this wasn’t quite correct and it ended up closing the child processes’ stderr.*<p>I generally use `set -e` (errexit) because I want my scripts to fail if any command fails (I consider that after an unhandled failure the script’s behavior is undefined, some other people disagree and say you should never use `set -e` outside of development, but I digress). My BROWSER scripts are no exception.<p>While my scripts handle non-zero returns for most things that can go wrong, I never considered that writing log messages to stdout or stderr might fail. But it did, which caused the script to die before it was able to launch my browser. For a few weeks I wasn’t able to use urlscan to open links. I was too lazy to figure out what was wrong, and when I did it took me a while because I looked into every possibility <i>except</i> this one.<p>Luckily this wasn’t a production app. But I know now it could just as feasibly happen in production, too.<p>I opened an issue[1] and it was fixed very quickly. I love open source!<p>*No disrespect to urlscan, it’s an awesome tool and bugs happen to all of us!<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;firecat53&#x2F;urlscan" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;firecat53&#x2F;urlscan</a><p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;firecat53&#x2F;urlscan&#x2F;issues&#x2F;122" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;firecat53&#x2F;urlscan&#x2F;issues&#x2F;122</a>
评论 #30612643 未加载
评论 #30613100 未加载
评论 #30614258 未加载
评论 #30619368 未加载
xlii大约 3 年前
I’m disappointed. I expected some obscure edgecase (like “Main is usually a function…” [1]) but instead that’s about scope handling, contract design and responsibility shift.<p>“Hello world” method simply calls an API to a text interface. It uses simple call, to a simple interface that is expected to be ever present. I don’t find any bug there. It won’t work if such interface isn’t available, is blocked or doesn’t exist. It won’t work on my coffee grinder nor on my screwdriver. It won’t work on my Arduino because there is no text interface neither.<p>Of course, one could argue that user might expect you to handle that error. That’s all about contracts and expectation. How should I deal with that? Is the “Hello world” message such important that the highest escalated scenario should be painted on the sky? I can imagine an awkward social game where we throw each other obscure challenges and call it a bug.<p>It’s nitpicking that even such simple code might fail and I get it. It will also fail on OOM, faulty hardware or if number of the processes on the machine hit the limit. Maybe some joker replaced bindings and it went straight to 3D printer which is out of material? _My expectations_ were higher based on the title.<p>Now allow me to excuse myself, I need to write an e-mail to my keyboard manufacturer because it seems like it has a bug which prevents it from working when slightly covered in liquid coffee.<p>[1]: <a href="http:&#x2F;&#x2F;jroweboy.github.io&#x2F;c&#x2F;asm&#x2F;2015&#x2F;01&#x2F;26&#x2F;when-is-main-not-a-function.html" rel="nofollow">http:&#x2F;&#x2F;jroweboy.github.io&#x2F;c&#x2F;asm&#x2F;2015&#x2F;01&#x2F;26&#x2F;when-is-main-not-...</a>
评论 #30614175 未加载
评论 #30612134 未加载
评论 #30612514 未加载
评论 #30623591 未加载
评论 #30613634 未加载
评论 #30613572 未加载
评论 #30613853 未加载
评论 #30612950 未加载
usrbinbash大约 3 年前
Enjoyable read for sure, but i think the question whether ot not this constitutes a bug or not is open for interpretation.<p>IMHO, it doesn&#x27;t.<p>hello.c is written in a way that makes it very clear that the program doesn&#x27;t care about error conditions in any way shape or form; the return value of printf is ignored, the output isn&#x27;t flushed, the return of flushing isn&#x27;t checked, noone looks at errno; ...so anything happening that could go wrong will go unreported, unless its something the OS can see (segfault, permission, etc.)<p>If I expect a program to do something (eg. handle IO errors) that its code says very clearly that it doesn&#x27;t, that&#x27;s not the programs fault.
评论 #30615139 未加载
评论 #30614144 未加载
评论 #30614062 未加载
评论 #30614303 未加载
评论 #30615189 未加载
pron大约 3 年前
To those perplexed by the behaviour of Java&#x27;s Hello World, as Java is otherwise very careful with error handling, this is because System.out is a java.io.PrintStream, and that&#x27;s its documented behaviour:[1]<p>&gt; Unlike other output streams, a PrintStream never throws an IOException; instead, exceptional situations merely set an internal flag that can be tested via the checkError method.<p>So the correct Hello World would be:<p><pre><code> System.out.println(&quot;Hello World!&quot;); if (System.out.checkError()) throw new IOException(); </code></pre> While the behaviour of PrintStream cannot be changed (it goes back to Java 1.0, and I&#x27;m guessing that the intention was not to require handling exceptions when writing messages to the standard output), adding a method to obtain the underlying, unwrapped OutputStream might be an idea worth considering, as it would allow writing to the standard output just like to any file.<p>[1]: <a href="https:&#x2F;&#x2F;docs.oracle.com&#x2F;en&#x2F;java&#x2F;javase&#x2F;17&#x2F;docs&#x2F;api&#x2F;java.base&#x2F;java&#x2F;io&#x2F;PrintStream.html" rel="nofollow">https:&#x2F;&#x2F;docs.oracle.com&#x2F;en&#x2F;java&#x2F;javase&#x2F;17&#x2F;docs&#x2F;api&#x2F;java.base...</a>
评论 #30613436 未加载
mccorrinall大约 3 年前
Imo this is because the responsibility is not clearly defined and can be argued upon.<p>If my program writes to the standard output, but you choose to redirect the pipe to a different location, is it my program’s responsibility to check what happens to the bytes AFTER the pipe?<p>After all: <i>my program did output everything as expected</i>. The part which fucked up was not part of my program.<p>I can see why some projects decide to not handle this bug.
评论 #30612499 未加载
评论 #30612133 未加载
评论 #30611838 未加载
评论 #30613280 未加载
评论 #30611978 未加载
评论 #30612480 未加载
评论 #30611804 未加载
评论 #30613764 未加载
bestouff大约 3 年前
Well that&#x27;s precisely the mindset of C&#x2F;C++. You have to think by yourself about everything that can go wrong with your code. And, man, lots of things can go wrong.<p>I find more modern languages so much less exhausting to use to write correct code.
评论 #30611808 未加载
评论 #30611653 未加载
评论 #30611703 未加载
评论 #30617767 未加载
评论 #30612091 未加载
评论 #30612746 未加载
评论 #30611676 未加载
hiccuphippo大约 3 年前
This is one of the reasons zig doesn&#x27;t have a print function and you have to deal with the error when using the stdout writer[0].<p>[0] <a href="https:&#x2F;&#x2F;zig.news&#x2F;kristoff&#x2F;where-is-print-in-zig-57e9" rel="nofollow">https:&#x2F;&#x2F;zig.news&#x2F;kristoff&#x2F;where-is-print-in-zig-57e9</a>
评论 #30612072 未加载
avar大约 3 年前
A real world example of catching (some, but certainly not all) fflush(), ferror() etc. cases is what &quot;git&quot; does at the end of its execution, the first highlighted line is where it&#x27;s returning from whatever function implements a built-in (&quot;status&quot;, &quot;pull&quot;, &quot;log&quot; etc. etc.): :<a href="https:&#x2F;&#x2F;github.com&#x2F;git&#x2F;git&#x2F;blob&#x2F;v2.35.0&#x2F;git.c#L464-L483" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;git&#x2F;git&#x2F;blob&#x2F;v2.35.0&#x2F;git.c#L464-L483</a><p>Doing something similar would be a good addition to any non-trivial C program that emits output on stdout and stderr.<p>In practice I haven&#x27;t really seen a reason to exhaustively check every write to stdout&#x2F;stderr as long as standard IO is used, and fflush() etc. is checked.<p>A much more common pitfall is when dealing with file I&#x2F;O and forgetting to check the return value of close(). In my experience it&#x27;s the most common case where code that <i>tries</i> to get it wrong actually gets it wrong, I&#x27;ve even seen code that checked the return value of open(), write() and fsync(), but forgot about the return value of close() before that fsync(). A close() will fail e.g. if the disk is full.
评论 #30614287 未加载
yesenadam大约 3 年前
I couldn&#x27;t see GNU Hello mentioned in the article or comments so far. I wonder how it fares bug-wise.<p><i>The GNU Hello program produces a familiar, friendly greeting. Yes, this is another implementation of the classic program that prints “Hello, world!” when you run it.</i><p><i>However, unlike the minimal version often seen, GNU Hello processes its argument list to modify its behavior, supports greetings in many languages, and so on. The primary purpose of GNU Hello is to demonstrate how to write other programs that do these things; it serves as a model for GNU coding standards and GNU maintainer practices.</i><p><a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;hello&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;hello&#x2F;</a>
评论 #30613718 未加载
tgv大约 3 年前
It&#x27;s a fun take, but a hyperbole nonetheless. hello.c is supposed to be run from a terminal and write back to it: there&#x27;s always space to write. It&#x27;s not meant to be part of a shell script, so the error status is irrelevant.<p>It does show that we take such examples a bit too literally: our feeble minds don&#x27;t consider what&#x27;s missing, until it&#x27;s too late. That&#x27;s a didactic problem. It only matters to certain kinds of software, and when we teach many people to program, most of them won&#x27;t go beyond a few small programs. But perhaps the &quot;second programming course&quot; should focus a bit less on OOP and introduce error handling.
评论 #30612043 未加载
评论 #30613464 未加载
评论 #30612322 未加载
Reventlov大约 3 年前
And to catch such a thing in C, if anyone was wondering, you would have to fflush stdout.
评论 #30611828 未加载
shultays大约 3 年前
Should &quot;hello world&quot; return error if it actually prints something but there was no person to read the output? Maybe the user was distracted and was not looking at the screen. Does a &quot;hello world&quot; program make sound if no one hears it?<p>Sounds like the program failed its objective, greeting the world. And thus imho shouldn&#x27;t return 0.
评论 #30613810 未加载
dwohnitmok大约 3 年前
This raises an interesting question: is there any IO function that should return unit&#x2F;void? Or equivalently are there any IO functions for which we can safely ignore the return value&#x2F;ignore all exceptions?<p>It seems like every single IO thing I can think of can have a relevant error, regardless of whether it&#x27;s file-system related, network, or anything else.
评论 #30611924 未加载
评论 #30611914 未加载
joosters大约 3 年前
Since the article is being pedantic, here&#x27;s another pedantic complaint: What if printf() can&#x27;t write <i>all</i> of its output, but manages to write some of it? printf() returns the number of bytes written, but (and I&#x27;m sure someone will correct me if I&#x27;m wrong!) it doesn&#x27;t guarantee to be atomic - it can&#x27;t either write everything or nothing. Imagine a complicated printf() call with lots of parameters and long strings - some of it might get written, then the next write() that it does fails due to lack of space. What does printf() do then?<p>The article cites an example of writing a YAML file and the dangers of it being half-written. Well, you could imagine outputting a file all in one printf() with lots of %s&#x27;s in the format string. Some get written, but not all. If printf() decides to return an error message, retrying the printf() later on (after deleting another file, say), will corrupt the data because you&#x27;ll be duplicating some of the output. But if printf() just returned the number of bytes written, your program will silently miss the error.<p>So does &#x27;Hello World\n&#x27; need to check that printf() succeeded, or does it actually need to go further and check that printf() returned 12? (or is it 13, for \r\n ?) I don&#x27;t think there&#x27;s any way to really safely use the function in real life.
评论 #30612693 未加载
评论 #30612712 未加载
kazinator大约 3 年前
&gt; <i>There&#x27;s our &quot;No space&quot; error getting reported by the OS, but no matter, the program silently swallows it and returns 0, the code for success. That&#x27;s a bug!</i><p>Bzzt, no. You can&#x27;t say that without knowing what the program&#x27;s requirements are.<p>Blindly &quot;fixing&quot; a program to indicate failure due to not being able to write to standard output could break something.<p>Maybe the output is just a diagnostic that&#x27;s not important, but some other program will reacts to the failed status, causing an issue.<p>Also, if a program produces output with a well-defined syntax, then the termination status may be superfluous; the truncation of the output can be detected by virtue of that syntax being incomplete.<p>E.g. JSON hello world fragment:<p><pre><code> puts(&quot;{\&quot;hello\&quot;:\&quot;world\&quot;}&quot;); return 0; </code></pre> if something is picking up the output and parsing it as JSON, it can deduce from a failed parse that the program didn&#x27;t complete, rather than going by termination status.
评论 #30614846 未加载
评论 #30612843 未加载
评论 #30615150 未加载
评论 #30612122 未加载
Ericson2314大约 3 年前
This is good. All the people questioning the spec need to realize is handling the error should be opt-<i>out</i>, not opt-in.<p>#[must_use] in Rust is the right idea: Rust doesn&#x27;t automatically do anything --- there is no policy foisted upon the programmer --- but it will reliably force the programmer to do <i>something</i> about the error explicitly.
pixelbeat__大约 3 年前
Jim Meyering&#x27;s classic &quot;Goodbye World&quot; talk on this<p><a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;ghm&#x2F;2011&#x2F;paris&#x2F;slides&#x2F;jim-meyering-goodbye-world.pdf" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;ghm&#x2F;2011&#x2F;paris&#x2F;slides&#x2F;jim-meyering-goodb...</a>
andi999大约 3 年前
It would be more interesting if the post shows how to detect that error. (and how the other language examples look, at least on mobile I dont see them)
moltenguardian大约 3 年前
Even Golang de facto suffers from this. I don&#x27;t think I can name a time I saw someone check the return value of fmt.Print or log.Print. Not checking the return value still seems the the &quot;right&quot; thing to do.
评论 #30611755 未加载
评论 #30614401 未加载
评论 #30611862 未加载
评论 #30612821 未加载
ale42大约 3 年前
I was expecting Free Pascal not to have the bug, as Pascal generally fails with a visible runtime error, as it does I&#x2F;O checking by default. However, it seems not to do it when WriteLn goes to the standard output... (even if it is then piped to &#x2F;dev&#x2F;full). So the basic<p><pre><code> begin WriteLn(&#x27;Hello World!&#x27;); end. </code></pre> definitely has the bug, at least with the fpc implementation. On the other hand, explicitly trying to write to &#x2F;dev&#x2F;full from the Pascal source triggers a beautiful message:<p><pre><code> Runtime error 101 at $0000000000401104</code></pre>
pickledcods大约 3 年前
Do not forget the notes on dup2(). It&#x27;s about the automatic closing of newfd before it gets replaced. I&#x27;ve bumped into this situation several times, that is why I&#x27;m mentioning it.<p><pre><code> SYNOPSIS int dup2(int oldfd, int newfd); NOTES: If newfd was open, any errors that would have been reported at close(2) time are lost. If this is of concern, then the correct approach is not to close newfd before calling dup2(), because of the race condition described above. Instead, code something like the following could be used: &#x2F;* Obtain a duplicate of &#x27;newfd&#x27; that can subsequently be used to check for close() errors; an EBADF error means that &#x27;newfd&#x27; was not open. *&#x2F; tmpfd = dup(newfd); if (tmpfd == -1 &amp;&amp; errno != EBADF) { &#x2F;* Handle unexpected dup() error *&#x2F; } &#x2F;* Atomically duplicate &#x27;oldfd&#x27; on &#x27;newfd&#x27; *&#x2F; if (dup2(oldfd, newfd) == -1) { &#x2F;* Handle dup2() error *&#x2F; } &#x2F;* Now check for close() errors on the file originally referred to by &#x27;newfd&#x27; *&#x2F; if (tmpfd != -1) { if (close(tmpfd) == -1) { &#x2F;* Handle errors from close *&#x2F; } }</code></pre>
bandrami大约 3 年前
This is interesting because it&#x27;s not clear &quot;who owns&quot; that error, the program itself or the shell that sets up the redirection.
评论 #30618852 未加载
评论 #30612814 未加载
paradite大约 3 年前
Since we are going pedantic here, here are 3 bugs that I found in the blogpost:<p>1. Node.js result is out-dated. I run on Node.js v14.15.1 hello world code below on macOS and it reported exit code 1 correctly:<p><pre><code> &#x2F;&#x2F; testlog.js console.log(&#x27;hello world&#x27;) process.exit(0) &#x2F;&#x2F; bash $ node -v v14.15.1 $ node testlog.js &gt; &#x2F;dev&#x2F;full -bash: &#x2F;dev&#x2F;full: Operation not permitted $ echo $? 1 </code></pre> 2. Node.js is not a language. JavaScript is a language, and Node.js is a JavaScript runtime environment that runs on the V8 engine and executes JavaScript code outside a web browser.<p>3. Missing JavaScript result in the table, which is the most popular language on GitHub: <a href="https:&#x2F;&#x2F;octoverse.github.com&#x2F;#top-languages-over-the-years" rel="nofollow">https:&#x2F;&#x2F;octoverse.github.com&#x2F;#top-languages-over-the-years</a>
评论 #30612293 未加载
评论 #30612764 未加载
评论 #30612686 未加载
评论 #30612449 未加载
sundarurfriend大约 3 年前
Julia (1.7) behaves pretty similar to the Python 2 one, a printed error related to closing the stream, and a 0 error code.<p><pre><code> ~ &gt;&gt;&gt; julia -e &#x27;print(&quot;Hello world&quot;)&#x27; &gt; &#x2F;dev&#x2F;full error in running finalizer: Base.SystemError(prefix=&quot;close&quot;, errnum=28, extrainfo=nothing) #systemerror#69 at .&#x2F;error.jl:174 systemerror##kw at .&#x2F;error.jl:174 systemerror##kw at .&#x2F;error.jl:174 #systemerror#68 at .&#x2F;error.jl:173 [inlined] systemerror at .&#x2F;error.jl:173 [inlined] close at .&#x2F;iostream.jl:63 ⋮ ~ &gt;&gt;&gt; echo $? 0 </code></pre> `errnum=28` apparently refers to the ENOSPC error: &quot;No space left on device&quot; as defined by POSIX.1; so the information is there, even if not in the most presentable form.
albertzeyer大约 3 年前
In the end, it states that the language C has the bug. But this is wrong. In C, there are no exceptions, i.e. all error checking has to be explicit. This is just the language. So when you now ignore the error, this is not a bug of the language but just a bug in your code. The only thing you could argue is that this is a bad language design.<p>Or maybe this about global stdout object. With buffering enabled (by default), printf will not throw any error. The fflush would do. But a final fflush would be done implicitly at the end. But this is again all well documented, so still, this is not really a bug but maybe just bad language design.<p>I&#x27;m not exactly sure what C++ code was used. If this was just the same C code, then the same thing applies. And iostream just behaves exactly as documented.
andai大约 3 年前
An interesting link in the article: &quot;Main is usually a function. So then when is it not?&quot;<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27504254" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27504254</a>
pretzelhands大约 3 年前
Seems like PHP does something reasonably right for once!<p><pre><code> $ php hello.php &gt; &#x2F;dev&#x2F;full $ echo $? 255 </code></pre> It doesn&#x27;t exactly print an error, but at least it returns something non-zero.
评论 #30612917 未加载
Sporktacular大约 3 年前
Still confused. It seems some people think there is nothing to fix, some think the programmer needs to act to prevent it, some think ANSI and other creators of the affected languages would need to act to prevent it.<p>If we accept the idea that the function (non-coding use of the word) of an language&#x27;s indication of success should - indicate success (or its absence) - of a piece of code, then surely the creators of the languages should make it do just that. That&#x27;s their job right no? What am I missing?
enriquto大约 3 年前
Ignoring the return of printf is a &quot;bug&quot;. For the hello-world example, you can simply pass the printf value to main: &quot;return printf(...) &gt; 0;&quot;
评论 #30611830 未加载
评论 #30612543 未加载
parker78大约 3 年前
It&#x27;s only a bug if the requirements are:<p>&quot;Print Hello World and indicate if it succeed or not&quot;<p>If the requirements were:<p>&quot;Print Hello World, then return 0&quot;<p>It&#x27;s working as intended.<p>I&#x27;d even go so far as to say that print(); return 0; should always return 0, it would be weird for such a program to ever return anything other than 0 (where would that return come from?).
评论 #30612715 未加载
评论 #30612852 未加载
评论 #30612735 未加载
prewett大约 3 年前
&#x2F;dev&#x2F;full is brilliant, I need to remember that!<p>On the other hand, it&#x27;s kind of depressing that I can&#x27;t even write to stdout without needing to check for errors. And what are you going to do if that fails? Write to stderr? What if that fails because the program was run with `2&gt;&amp;1` ?
bor0大约 3 年前
It&#x27;s a good post, but heavily OS dependant. For example, on my Mac:<p><pre><code> $ ls &#x2F;dev&#x2F;null &#x2F;dev&#x2F;full ls: &#x2F;dev&#x2F;full: No such file or directory &#x2F;dev&#x2F;null </code></pre> I guess in theory, you can imitate `&#x2F;dev&#x2F;full` by other means.
评论 #30611880 未加载
评论 #30612613 未加载
评论 #30613090 未加载
hwinked大约 3 年前
I don’t think this is a bug. The program writes to stdout which is guaranteed by *ix to be there. If it is full, it would block until the kernel serviced it. In your examples, the user asked the shell to redirect to a full file and it reported the error.
skolskoly大约 3 年前
Doesn&#x27;t seem like anyone has posted the bug free implementation so here it is:<p><pre><code> int main(void) { char the_terminal[] = &quot;Hello World!\n&quot; return 0; }</code></pre>
lifeisstillgood大约 3 年前
This is (IMHO) the difference between unit testing and other testing.<p>Unit testing verifies it does what it is supposed to do <i>ideally</i>, and all other tests verify it can do it in non-ideal environments.
s_ariga大约 3 年前
#include &lt;stdio.h&gt; #include &lt;stdlib.h&gt;<p>int main(void) { if(puts(&quot;Hello, World!&quot;)!=EOF) { return EXIT_SUCCESS; }else { return EXIT_FAILURE; } }
评论 #30612553 未加载
评论 #30612466 未加载
评论 #30612518 未加载
评论 #30612502 未加载
asojfdowgh大约 3 年前
And not an edge case in the slightest either.<p>I&#x27;m going to have to go back over all the print statements I&#x27;ve ever written now
评论 #30611736 未加载
RcouF1uZ4gsC大约 3 年前
What happens if in the original hello world example, you unplugged the monitor?<p>Would any of the languages report an error?<p>Maybe they all have bugs.
kaycebasques大约 3 年前
The article doesn&#x27;t explain how to fix the bug! Talk about leaving your audience hanging.
评论 #30623717 未加载
fouronnes3大约 3 年前
Curious if Zig&#x27;s &quot;software should be perfect&quot; suffers from this.
评论 #30612166 未加载
edejong大约 3 年前
Correct solution:<p><pre><code> printf &#x27;#include &lt;stdio.h&gt;\nint main() { return printf(&quot;Hello world!\\n&quot;) &amp;&amp; fflush(stdout); }\n&#x27; | cc -xc - &amp;&amp; .&#x2F;a.out &gt; &#x2F;dev&#x2F;full &amp;&amp; echo &quot;Success\!&quot;</code></pre>
评论 #30614089 未加载
darkerside大约 3 年前
TIL about &#x2F;dev&#x2F;full<p>Could have used this knowledge in the past...
评论 #30616115 未加载
sedatk大约 3 年前
Did the author just assume the spec of Hello World?
8n4vidtmkvmk大约 3 年前
ok but how does one fix this bug in c or c++?
评论 #30612570 未加载
bradwood大约 3 年前
Here&#x27;s another one:<p>10 PRINT &quot;Hell world&quot;
steerablesafe大约 3 年前
You can&#x27;t have bugs if you don&#x27;t have a specification. [insert meme here]
thedatamonger大约 3 年前
Bravo! I enjoyed this.
inopinatus大约 3 年前
tldr: always check the return value of system calls.<p>(also, printf is buffered, so close or flush your output)
karolist大约 3 年前
The author missed another bug, which many others do. You need a comma after Hello, as in &quot;Hello, World!&quot; because it&#x27;s a direct address. Very, and I mean VERY few books get this right.<p>0. <a href="https:&#x2F;&#x2F;www.grammar-monster.com&#x2F;lessons&#x2F;commas_with_vocative_case.htm" rel="nofollow">https:&#x2F;&#x2F;www.grammar-monster.com&#x2F;lessons&#x2F;commas_with_vocative...</a>
评论 #30619315 未加载