Language:
switch to room list switch to menu My folders
Go to page: First ... 72 73 74 75 [76] 77 78 79 80 ... Last
[#] Wed Mar 30 2011 04:54:09 EDT from dothebart @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

yes. clang was started out as a research project, c/c++ are compiled into intermediate code (which you could deliver as sort of the usual firmware BLOB)

it has some possibilities to find more errors by code analysis, and it has the ability to give you error messages that realy point you to all aspects of an error not just give you a vague idea what it is, and leaves the rest upon your interpretation; Take for example a header with a class with missing semicolon as last thing: class foo {}<EOF> GCC will report the error in your next include. Clang also does a much better job of unwinding defines and tell you where you have errors within them or their useage. Next due to the late linkeage, clang can do better optimization across .o borders (like inline functions...), which GCC can't by definition.

next to that GCC got a little old and clumsy, even the re-merged EGCS doesn't have left much of its effect to bring the will of innovation. Two years ago GCC was a little like IE6 in 2005: its there, its got the market dominance and there were no real alternatives, its sort of like all monopolies are bad, even in opensource. Now theres CLANG to have other ways to find a way ahead, which might bear innovations, which GCC developers might not even think about, just because of its complicated to implement in their code-base.

So, you see there are several good reasons to have CLANG around, be its compiled code more effective than gcc or not.

 



[#] Wed Mar 30 2011 13:09:41 EDT from Ford II @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

linkeage, clang can do better optimization across .o borders (like
inline functions...), which GCC can't by definition.

Yeah, I read that somewhere. What a load of shit. That works well only if you completely ignore the efficiency lost TO AN ENTIRE LAYER OF INTERPRETATION.
Their argument that they can find better optimizations by writing to a uniform interpreter takes away ANY possibility of optomizing for the actual platform you're running on.
programmers have turned into politicians, and all politicians are assholes.

[#] Wed Mar 30 2011 19:09:43 EDT from dothebart @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

 

Mi Mär 30 2011 13:09:41 EDT von Ford II @ Uncensored Betreff: Re:
linkeage, clang can do better optimization across .o borders (like
inline functions...), which GCC can't by definition.

Yeah, I read that somewhere. What a load of shit. That works well only if you completely ignore the efficiency lost TO AN ENTIRE LAYER OF INTERPRETATION.
Their argument that they can find better optimizations by writing to a uniform interpreter takes away ANY possibility of optomizing for the actual platform you're running on.
programmers have turned into politicians, and all politicians are assholes.

we'll see whether they manage to catch up in performance with GCC ;-P until that the GCC developers have something to stare at in their rearview mirror (in performance) and something to catch up to (in better error messages)

in other points, it even finds some more errors, which one might have to search with valgrind otherwise.



[#] Thu Mar 31 2011 15:26:04 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Perfect use case for closures:

You have a ThreadPoolManager that kicks off function pointers (closures, objects, whatever) to worker threads. It implements a couple of methods:


void execute(Function foo) // schedule for asynchronous execution asap
void schedule(Function foo, int delay) // schedule after a delay

Foo wants to try some task that might fail, so if it fails, it wants to reschedule itself after a retry delay, by calling back to the scheduler and passing itself back. In a non-GC'd environment, this interface style doesn't entirely work (who's responsible for calling free()?) and probably needs to be redefined in a much less convenient fashion.


Doing the time warp this way, is much easier.

[#] Fri Apr 01 2011 06:13:12 EDT from argeorge @ Uncensored

Subject: POP3 Service STLS Plaintext Command Injection

[Reply] [ReplyQuoted] [Headers] [Print]

security tool found:

 

POP3 Service STLS Plaintext Command Injection


Synopsis
The remote mail service allows plaintext command injection while negotiating an encrypted communications channel.

List of Hosts

x.x.x.x

Plugin Output

Nessus sent the following two commands in a single packet :

STLS\r\nCAPA\r\n

And the server sent the following two responses :

+OK Begin TLS negotiation now
+OK Capability list follows


 


Description
The remote POP3 service contains a software flaw in its STLS
implementation that could allow a remote unauthenticated attacker to
inject commands during the plaintext protocol phase that will be
executed during the ciphertext protocol phase. 

Successful exploitation could allow an attacker to steal a victim's
email or associated SASL (Simple Authentication and Security Layer)
credentials.


Solution
Contact the vendor to see if an update is available.




[#] Fri Apr 01 2011 10:31:47 EDT from skpacman @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

blargh... since when did mozilla make firefox so damn critical of where you put a <tbody>?!? IE, Opera, Chrome, and Safari didn't care, why did Firefox4?



[#] Fri Apr 01 2011 14:54:28 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Doing the time warp this way, is much easier.

Yes, but that's sort of the cart following the horse.
If you don't have closures you wouldn't design something with memory ownership being ambiguous.
the fact that closures rely on GC says more for GC than it does for closures.


Ford (good bad or ugly, I still think Flying Scope is a better name) ][

[#] Fri Apr 01 2011 15:37:28 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I like how they say pop3 this broken, doesn't mention WHO's implementation is broken.

[#] Fri Apr 01 2011 17:01:36 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

If you don't have closures you wouldn't design something with memory

ownership being ambiguous.

Actually this API looks almost identical with a plain old Java-esque object system rather than closures...

[#] Fri Apr 01 2011 17:46:26 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

thus the value add here is gc not closures...

[#] Sat Apr 02 2011 00:34:30 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Well, closures are different from objects in the first place only in surface syntax... so the whole discussion is kind of a handwave to begin with. But if you're going to create a lot of reusable control structures and threads, the braces nest more nicely ;)

[#] Sun Apr 03 2011 16:24:36 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

yes they do in fact you make a good point that you don't know what other shit you're carrying along with you while your closure is still alive.
Java sucks that way too, since there are no destructors because you never really know when your object is going to go away you have to take care to make sure your object is safely put to bed when you need it to be, because you can't rely on the GC to do it for you in a timely manner.
Same problem with closures, you could have a threadpool or something crazy like that hanging out because you have a very nested closure still in existance.

[#] Mon Apr 04 2011 16:58:21 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


If you think that's bad, try doing lightweight task scheduling with continuations >:-) -- for job security of course!


[#] Thu Apr 07 2011 12:13:14 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Isn't task scheduling the operating system's job?

[#] Fri Apr 08 2011 11:36:09 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


No! Not if you're doing a lot of CPU-intensive computation. Even on a multicore CPU, communication costs related to context switching and inter-thread communication can be quite large. There's a big latency penalty when you have to reach beyond your core's local cache to the shared cache.

So for pure CPU-intensive work, the name of the game is to build a pool of n threads, where n typically equals the number of hardware threads. The number of lightweight tasks typically exceeds the number of threads, so these are cooperatively scheduled in such a way as to maximize locality. Where possible, threads execute their ownn subtasks, but where this is not possible, another thread will step in to help via work stealing. To minimize communication costs, the amount of work stolen must be relatively large. C.f. ParallelArray.

[#] Fri Apr 08 2011 11:45:40 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Programming anti-pattern #35471: a library or service you use chose a perfectly good name for something. Make sure you rename it within your layer, because it isn't "your" name.

[#] Sat Apr 09 2011 11:43:13 EDT from IGnatius T Foobar @ Uncensored

Subject: Re:

[Reply] [ReplyQuoted] [Headers] [Print]

What if the library or service contains object names with obvious spelling errors?  That drives me crazy!



[#] Mon Apr 11 2011 13:49:52 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


***You must maintain the original names, complete with speling errors!***

[#] Mon Apr 11 2011 16:07:43 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Thanks LS, you made me recall how Savio Lam misspelled "gauge" all those years ago, and after revisiting the issue I've discovered that "whiptail" has *completely* replaced "dialog" on pretty much every Linux system I checked. Now I can build that test back into my installation scripts again. :)

[#] Tue Apr 12 2011 17:11:58 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Glad to be of help (?)

Go to page: First ... 72 73 74 75 [76] 77 78 79 80 ... Last