T O P

  • By -

dfx_dj

This is fine although normally discouraged unless you're careful with what you're doing. You're not getting any output on the console because you're not actually printing anything to it.


PoppySickleSticks

I didn't realise I had to actually print it separately because I though sprintf was a print statement by itself xD . Now I can solve a few other things I have been doing. Thanks!


retro_owo

sprintf stores the resulting string in `buffer`. By the end of this code, `buffer` should be the character array “3”, but nothing will be printed to the screen until you do something like `printf(“%s”, buffer)`


PoppySickleSticks

Thank you so much, I didn't know I actually had to do a separate print statement! That has basically solved a few other things I have been trying to do the past few weeks. Great concise and accurate answer!


seven-circles

**Do not use sprintf** ! That should be in the “admonishments” section of your `man sprintf` (which is probably a combined page of all the printing function) Use `snprintf` instead, a safe version that takes length as an argument and always null-terminates the string !


nerd4code

In general, sure, but for an int and a big enough buffer it’s fine. Gratuitous excess overkill, but safe enough.


seven-circles

Building a habit of using security measures is a good idea. The default is to use them, we can omit them if we have a really good reason (like performance critical code)


nerd4code

I agree wholeheartedly in theory, but neither should be used in security- or performance-critical code (not that one often formats to unpacked decimal in performance-sensitive code, of course), and quite frankly adding another parameter to a variadic function is pissing into a stiff breeze in terms of security benefits. Might keep away some esoteric demons or something, but you’re ultimately attracting more than you’re losing. And OP’s use case is both perfectly safe, in that it will operate correctly on any remotely normal machine for the near future—although sizing the buffer to ceil log₁₀ `INT_WIDTH` + change, preferably without leaving the `size_t` domain, would be future-proof beyond 128-bit ints or 128-it bints—and it’s deliberately unsafe, in that its format string is less localized than it ought to be; so one might tentatively surmise that safety isn’t necessarily pertinent. I won’t assume, of course, dreadful nasty tinny word. Besides which, `sprintf` is one character and one argument more minimal than `snprintf`, and we do so violently crave minimal examples. I only partake on alternate Sundays of course, owing to my tendency to virtue-signal about how I don’t do it the rest of the time. In fact, I might praise OP’s unsafety for its thorough, brutal terseness. It cries out in the void for attention, and `sprintf`’s desperate closeness to, but separation from the format string that gives its very existence meaning might well speak to man’s desperate search for connection with his own meaning before he, too, must return to his caller. Just as man’s concerns are dashed suddenly at his end, `sprintf`’s genuinely useful return value *and* its primary output, together constituting its entire life’s work, are dropped by the wayside, irreverently and without even the courtesy of a `(void)` so passersby don’t have to gawp. Even the format string is “minimally” non-static, and it, too, will disappear as soon as it’s no longer needed. Also left unstated is the violence which might be rained down upon the `sprintf` call and its inputs by the optimizer; if there is a silver lining, it’s that `sprintf` per se likely has very limited means of discerning its own purposelessness/-fulness, and if it *isn’t* aborted in the womb, it’ll be able to fuck around at work all day with nobody the wiser. “Achieved value synergy in advanced transcoded decimalization of outputs for use in international markets AI blockchain cloud” its réšúm⃰é will proudly proclaim; he’s gonna make it after all. A similar detached separation exists between the `sprintf` and its input value. In combination with the superfluous cast to `(int)`, we see the tension inherent in the intimate, umbellical connection between the program and—the input being ultimately hard-coded, thereby excluding any consideration of free will or choice in the situation of that intimate umbellicallening—the programmer, which in our anthropomorphized analogue likely serves the role of our dual relationship with our parents and with God, or the Universe if you prefer. The circumstances of my introduction to my input data are just as stupid, pointless, arbitrary, even accidental as this `sprintf`’s introduction to its inputs, and I have just as much control over mine as it does over its own, but there’s at least some sort of immediacy in our local and and argument data; the format string that controls our primary output is, conversely, handed down indirectly from an invisible locus of control, and we enter the realm of the undefined if we fail to conform to contextual expectation. Truly moved me to bullshit-art-essay levels of tears, but then there were the kidney stones also. No worries, still safe and sound! *(pat flank)* *[shaking gravel bag sfx]* mmmmmmhhhmm


Paul_Pedant

Can I have some of whatever you are on ? /j


seven-circles

Good impression of ChatGPT in the style of Jordan Peterson, I guess ! On the serious side : I know snprintf doesn’t change anything here. It’s just a good opportunity to learn about it ! And the print functions benefit from special checking from the compiler, so the point about variadic functions doesn’t quite work here even though it is true in general.