Computing desk
< July 22	<< Jun \| July \| Aug >>	July 24 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

July 23

C++ pointer question

Let's say I have a local variable and a pointer. I assign the address of the the variable to it. When the variable is removed from the stack, does the pointer become a stray pointer? Thanks Kayau (talk · contribs) 06:57, 23 July 2015 (UTC)[reply]

Yes, the address of a local variable should not be returned, because its lifetime will end when the function returns. Notice that you *may* be able to use the address, as it is still on the stack and the program can access the stack at any time, but you should *not* rely on it, as it is not guaranteed. Look at the following example:

#include <iostream>

int *f1(void)
{
	int localvar;
	int *localptr;
	localvar = 5;

	localptr = &localvar;

	return localptr;

}

void f2(void)
{
	int a = 20;
	int b = 30;
	int d = 50;
	/* dummy function, but calling it will rewrite the stack */

}

int
main(int argc, char *argv[])
{
	int *mainptr;

	mainptr = f1();

	/* will print 5 */
	std::cout << *mainptr << std::endl; /* the lifetime of the local vars have ended, but they are still valid
				     since the stack doesn't changed, so you should not rely on them */

	f2(); /* this will rewrite the stack */

	/* now let's try printing the number one more time */
	std::cout << *mainptr << std::endl; /* will not print 5, but a junk value */
	return 0;
}

The output is as follows on my system:

> ./a.out 
5
20

Thanks for the detailed answer. The example was very easy to understand. :) Kayau (talk · contribs) 17:31, 23 July 2015 (UTC)[reply]

A very similar question came up on StackOverflow yesterday. The poster observed that, although a returned pointer to a local array became invalid, it was transiently valid if observed using gdb before another called function had the opportunity to trash it. (Needless to say, this is all hugely sketchy and should never be relied upon!) —Steve Summit (talk) 19:24, 23 July 2015 (UTC)[reply]

First paint bucket tool?

What was the first consumer available graphics editor to have a "paint bucket" fill tool? We have an article Flood fill which doesn't discuss early implementations. I know MacPaint had it in 1984. Is there an earlier example? Staecker (talk) 14:18, 23 July 2015 (UTC)[reply]

This is going to be tricky... the algorithm existed since - well, it probably preceded the digital computer! Flood fill is, at its core, just a recursive search with path marking. One of the most obvious applications of this algorithm is to mark a two-dimensional array of data that represents a raster graphic. Raster graphics have existed for a long time, too... they also preceded the interactive graphical user interface. As you dive deeper into the history of computer application software, graphics editing looks a lot more like software programming; there isn't a hard "line" where suddenly consumers had access to point-and-click tools. It was a gradual transition.

You can read early history of computer graphics. Sketchpad (1963) constitutes what I would call "Application Software"; but it was designed in the late 1950s for the TX-2, and when you look at the details of machines from that era, it's not straightforward to distinguish "applications" from "system software" or even from "hardware." The author, Ivan Sutherland, implemented a recursive function (!) infrastructure for copying picture elements; but this recursion did not appear to be used for raster graphics. (Well, it's sort of on the boundary: the computer used a sparse matrix to represent a framebuffer, so it's almost modern and incredibly efficient!) The Sketchpad software even had a "graphical user interface." This infrastructure could have permitted the user (programmer!) to program a "flood fill," but that feature is not one that is described in the author's thesis. The distinction between "software user" and "software programmer" is a more recent invention than these machines! So I think it's fair to say that a user of Sketchpad could have used "flood fill."

Almost all of the early work on CAD involved graphical user interfaces: it was, of course, originally meant to stand for computer aided drafting. I expect if you deep-dive this history, you'll find a steady progression towards greater usability.

Here's Filling algorithms for raster graphics, presented by Theo Pavlidis at SIGGRAPH 1978. Apparently "flood fill" was novel enough for SIGGRAPH... but then again, the Porter-Duff algorithm was amazingly still considered novel in 1984... yes, things can be in front of other things.

Nimur (talk) 15:47, 23 July 2015 (UTC)[reply]

Thanks- I agree the algorithm is "obvious" to the point of not having a specific origin. Sketchpad is a great example, but as you say none of its 40 buttons did a flood fill. (I'm no expert, but it doesn't seem to do any shading or "filling" at all.)

I see PCPaint has a paint-roller tool- anybody know what that button does? Staecker (talk) 18:42, 23 July 2015 (UTC)[reply]

In defense of the Porter and Duff alpha-blending paper, (a) image compositing ("things in front of other things") goes back to the 19th century and they certainly don't claim that as original; (b) αx + (1−α)y alpha blending they also describe as "well known" already, and their approach is rather more sophisticated; (c) their algorithm is based on an assumption that's generally false (that the portions of each pixel obscured by each image are "statistically independent") and it's not obvious that it will give useful results in practice given that dubious foundation, so there's value in people from Lucasfilm disclosing that it works well enough for their feature-film special effects or whatever it was they worked on. -- BenRG (talk) 22:26, 23 July 2015 (UTC)[reply]

I know I implemented flood fill in my graphic editor "Gredi", really only intended for my own use (but a publisher grabbed it anyways and offered it to the masses, which largely and rightly ignored it). I'm not sure when I wrote that, but it was reviewed in computer magazine in 1985, and I borrowed the flood fill idea from somewhere earlier and the concrete algorithm from Chip magazine. So by that time flood fill already was well known and well understood. I'm fairly sure that Sinclair ZX Spectrum and Commodore 64 graphics programs has flood fill not later than late 1982. --Stephan Schulz (talk) 19:29, 23 July 2015 (UTC)[reply]

The Hobbit (1982 video game) certainly does (youtube). user:87.114.100.65 sits down and starts singing about gold @ 19:46, 23 July 2015 (UTC)[reply]

Picture MW Analyzer

Hi. Does someone know a online site that specifically analyzes Pics (.jpg, .png., etc.) for Malware hidden inside (shellcode php etc.). The reason mainly is that i found a suspicious picture @ commons, that includes a Web-injection and some suspicious Shellcode. However i do not mean Virus Total or anything likely (because i already analyzed it there), but a online site as mentioned, that just focuses on pics (or pdf) files. Thanks for some advice. 83.99.17.37 (talk) 22:11, 23 July 2015 (UTC)[reply]

I didn't find any such site in a brief search. It would be an oddly specific thing to specialize in. Did VirusTotal fail to detect the malware? Which image is it? -- BenRG (talk) 02:04, 24 July 2015 (UTC)[reply]

Hi. I moved my question @ Commons from the Diskpage of Admin Jameslwoodward (as he is offline for the moment) to Yann. If you have a special(wiki)mailadress, i can send you some more specific Details. The reason why is the one you can read at Yanns Diskpage. Regards --Gary Dee 15:42, 24 July 2015 (UTC)[reply]

If someone has advice, please join the discussion @ https://commons.wikimedia.org/wiki/User_talk:Yann Yann

thx --Gary Dee 16:57, 24 July 2015 (UTC)[reply]

Hi, Two engineers from the WMF looked at it, and saw no issue. Regards, Yann (talk) 08:27, 26 July 2015 (UTC)[reply]