Attach the native entry struct to the ArchiveEntry object.

Attach the native entry struct to the ArchiveEntry object.

This allows the entry properties to be set by the user.

Committed: https://code.google.com/p/dart/source/detail?r=10202

[Bob Nystrom, 2012-08-02 18:18:25]

It would be good to get one of the Dart embedding API people to look this over
at some point too. Most of it is mysterious to me.

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/entry.c
File utils/archive/entry.c (right):

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/entry.c#...
utils/archive/entry.c:30: DART_STRING(hardlink, (char*)
archive_entry_hardlink(e))
Not having semicolons after these looks scary to me. The macro inserts it, I but
it still looks weird. Add them?

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/entry_re...
File utils/archive/entry_request.dart (right):

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/entry_re...
utils/archive/entry_request.dart:12: final int CLONE = 28;
These values need to not overlap the ones in read_request for Bad Things(tm)
will happen. How about either defining them all in one file, or defining the
ones here based on a constant from read_request, like:

final int FREE = read.NUM_IDS + 1;
final int NEW = read.NUM_IDS + 2;
...

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/messaging.h
File utils/archive/messaging.h (right):

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/messagin...
utils/archive/messaging.h:57: * Returns `true` if an error is detected and the
containing function should
Returning "true" on failure feels backwards to me. How about something like
"validatePointer" which returns "false" on error?

[nweiz, 2012-08-02 21:32:27]

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/entry.c
File utils/archive/entry.c (right):

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/entry.c#...
utils/archive/entry.c:30: DART_STRING(hardlink, (char*)
archive_entry_hardlink(e))
On 2012/08/02 18:18:25, Bob Nystrom wrote:
> Not having semicolons after these looks scary to me. The macro inserts it, I
but
> it still looks weird. Add them?

Done.

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/entry_re...
File utils/archive/entry_request.dart (right):

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/entry_re...
utils/archive/entry_request.dart:12: final int CLONE = 28;
On 2012/08/02 18:18:25, Bob Nystrom wrote:
> These values need to not overlap the ones in read_request for Bad Things(tm)
> will happen. How about either defining them all in one file, or defining the
> ones here based on a constant from read_request, like:
> 
> final int FREE = read.NUM_IDS + 1;
> final int NEW = read.NUM_IDS + 2;
> ...

Done.

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/messaging.h
File utils/archive/messaging.h (right):

https://chromiumcodereview.appspot.com/10832116/diff/1/utils/archive/messagin...
utils/archive/messaging.h:57: * Returns `true` if an error is detected and the
containing function should
On 2012/08/02 18:18:25, Bob Nystrom wrote:
> Returning "true" on failure feels backwards to me. How about something like
> "validatePointer" which returns "false" on error?

Every single time you want to call this and related methods, it will be in the
context of "if (check*(...)) return". While I agree that in a stand-alone API,
returning false for errors makes more sense, in this case I don't think it's
worth adding a bunch of extra negation tokens for no real gain.

[Bob Nystrom, 2012-08-02 22:29:03]

LGTM!