Search results

Try using fflush like this: printf("%s",outputbuffer); fflush(stdout); // Add this in your readOut() function. Not sure if it will solve your problem. But the buffered I/O could be a problem. Or use setbuf to switch stdout to unbuffered I/O in your main() function: setbuf(stdout, NULL);

Maybe you can demonstrate the issue by using ffmpeg to capture an X11 terminal session. I created a script that you can use to easily capture a specific window and it can be found here. You may have to tweak it to output a video instead of a sequence of images. My post on the script also...

I don't know your exact problem since I can't compile or test your program. However, if your problems are thread related, you could always use select to deal with both stdin and mainfd serially. This removes your use of threads completely. I've modified your code as follows: int mainfd=0...

I know that Linux rand() uses random() underneath. So that would explain the expected behavior. If FreeBSD uses the traditional rand(), then the lower order bits (such as the last 3 bits or mod 8) will not be very random.

No, that's not what I'm saying at all. I'm saying that there are thousands of ports written in C++ and several utilities in the source tree written in C++ that rely on standard language behavior (such as catching exceptions!). It's not a just mere annoyance ... it's a serious problem that...

I think the ticket should be classed critical with priority high. It's a fundamental feature of the C++ language that should never have problems.

That's certainly strange. I originally thought it was a bug in GCC 4.2, but it affects clang and GCC 4.6 also. Maybe you should file a ticket.

While they two may be identical, the name of the executable determines the behavior. Use clang++.

Try using clang++ instead. I think clang is for C.

Because there are some things that POSIX cannot do. It's not necessarily the Linux developers' fault (though it probably is). But at some point, you run into an OS-specific or device-specific problem where there is no POSIX support and you have no choice but to use OS-specific API. Besides...

The application is for FreeBSD ports. Where would he reuse it? Yes, he could use the POSIX API ... but why? It's for FreeBSD! He has the FreeBSD API at his disposal. Why limit yourself? It's not even a practical consideration. EDIT: Furthermore, but being overly general (like supporting every...

pkgsrc is not ports although it is similar. Ports probably could be made to be portable, but it's not and probably won't be in the foreseeable future. EDIT: portmaster isn't even available from OpenBSD ports (The Original Poster did mention using it). My guess is that OpenBSD ports is very...

But he's writing this for ports ... it's already automatically not portable.

While I also like ftw(3), it doesn't allow you to pass an arbitrary argument pointer. Instead you have to expose your argument as a global variable. This is certainly OK if you don't plan to have several instances traversing directories. To be fair, I understand that fts(3) is not necessarily...

fts(3) shouldn't be any slower than using dirent. Use FTS_NOSTAT if you don't need to query permissions, user and group ids ... this should make it much faster. To store the vector of strings, just vDirectories.push_back(pFtsEntry->fts_path) instead of puts(pFtsEntry->fts_path) and there you...

Nothing. But since he's writing this for FreeBSD, he has ftw(3) and fts(3) at his disposal.

I think fts(3) is the easiest way to do this. You can look at find(1)'s source code as it uses fts(3). EDIT: Example: Visit all directories in /usr/ports recursively. FTS *pFtsCtx; FTSENT *pFtsEntry; char * const pathv[2] = { "/usr/ports", NULL }; pFtsCtx = fts_open(pathv, FTS_NOSTAT...

Doug Barton left!? When did that happen? That's a terrible loss!!! Is there a mailing list post detailing his departure? I'm quite saddened by this ...

C99 has restrict pointers and inline functions (which are very confusing compared to C++ inline) ... these are the biggest reasons you should learn C99. C99 struct initialization is nice as is the variadic macro support. It also has some other niceties that were standard in POSIX prior to C99...

Historically, we've been advancing in technology ... and it's still pretty reliable (sometimes even more-so than older and simpler technology). Granted, more parts does make for more points of failure. The real kicker is that machine learning methods build themselves (small chance for human...