Using brute force is not very effective on 256 keys. But this doesn't exclude the possibility of a breakthrough that reduce enormously the search space. For example even for AES there is an attack faster than brute force by a factor of about four ! http://research.microsoft.com/en-us/projects/cryptanalysis/a...

I think that it can be implemented in constant time for floating point numbers. For integers I know that the exponentiation by squaring takes O(log(n))

There are plenty. The analysis of basic algorithms involve math (e.g. QuickSort, binary search, etc). Programming a user friendly website can involve advanced mathematics, for example you want to recommend to your users a product that might interest them (Collaborative Filtering)

The PDF document format is incredibly complex. It can incorporate JavaScript actions !

They are not needed to parse the file. PDFs can also contain Flash content or movies or 3D models or any number of other objects. It's just a blob in the file, same as OLE. Few applications beyond Adobe Reader care about implementing those parts, though.

I think that MS R&D is valuable for the research community because they do publish in peer reviewed journals.

He works at Netgem a french start-up. It's not really a big corporate.

I know (well at least internet sources told me) he worked for a government agency in France similar to NSA in USA.

Probably still is, and netgem is his cover.

Why would he need to cover up that he is working for a government agency?

Considering that you apparently aren't fooled by that cover up, it can't be that much worth anyway.

The idea is anytime someone is on to him, someone like you will counter-argue, giving him the perfect cover.

For me sometimes it switches to Arabic even if I set the settings. And here in north Africa most people are francophone and prefer French or English !

I don't know why it uses a garbage collector when simple reference counting would suffice. Also I hate libraries with global states/variables like this one ...

I will likely remove the global state at some point, but the garbage collector is not something I plan to implement myself.

How would you implement refcounting in the presence of longjmp? I don't see a graceful way to do it.

I am not sure I grok the code, but I think something along the following lines would work:

  - a 'recovery' list of (object pointer, old refcount) pairs
  - whenever you allocate something, add (object pointer, 0) to the list
  - when you update a reference count, check whether the object is in the list.
    If it is not, add it to the list, thus remembering the original refcount
  - whenever the code decreases reference count to zero, add the object to a
   'to be deleted' list (this could possibly be a linked list chained through
    the 'refcount' fields; the old refcount will be in the recovery list)
  - when the parser reaches toplevel without longjmp, clear the first list,
    and delete any objects in the 'to be deleted' list.
  - when a longjmp occurs, walk the list and reset reference counts. For
    zero 'old refcounts', delete the object

Elegant? Not really, but with proper macros/functions, it should not be much less elegant than reference counting on its own.

That's pretty close to Deutsch-Bobrow deferred referenced counting. If you decide to implement it, you may want to read their paper about the technique.

I don't like C libraries that use longjmp for error handling. It's like killing a fly with a bazooka. There are some cases when longjmp is useful of course, but If you want proper exceptions, use a language that supports them.

The OP is doing awesome stuff and sharing it with the world, and you want to criticize an implementation detail?

Bikeshedding like this isn't useful to anyone.

I appreciate the OP's efforts, certainly sharing code is a good thing. And one of the benefits of the sharing is to get a lot of feedback. Criticizing implementation details is important to spot, discuss and hopefully fix potential problems.

But the only actionable advice you can take away from the criticism is "rewrite it in C++". I don't think that's in any way useful and I don't think it should be made.

Right - "Don't use longjmp, do X in C instead" would have been a useful comment (particularly with example code). "Don't use longjmp, use C++ instead" is much less useful.

I agree that my comment was a bit harsh, but that's not what I said. I said that if he wanted exceptions he shouldn't have used C.

As for the alternatives, well return values never killed anyone, did they? You can use gotos to simplify the control flow within the functions. Other than that, there really isn't much to explain.

I don't like longjmp because I never expect them in C. I never think "hey, the control flow might jump to some point 20 stack frames above at any moment when I enter this library". And then I use mutexes. Cue the drama. You can't even protect yourself from the stack unwinding with handler-case or try ... catch/except.

This. The headline was a parser combinator in C. The author is working with what he's got. Can't argue with the hangups that come with it, unless he makes some claim that his language choice is somehow superior to another, which I don't see happening here.

If I release code, having it criticized is a benefit. I want to learn from others, hear what they think of the design decisions, what they would have done differently, and what they think I did stupidly.

If you criticize my work, you're doing me a favor.

One could exploit the continuity of the image regions. (The similarity of neighbors in intensity and colors). Also the output is an image with the same histogram ...

The migration from MS Office to LibreOffice is not straightforward, especially if you have millions of documents. In my experience, any complex document will almost always fail to render correctly ...