Both for the essentially the same code: in the former: static bool BuildDate(JSContext *cx, unsigned argc, JS::Value *vp) { JS::CallArgs args = JS::CallArgsFromVp(argc, vp); fprintf(stdout, "built on %s at %s\n", __DATE__, __TIME__); args.rval().setUndefined(); return true; } in the latter: static bool BuildDate(JSContext* cx, unsigned argc, jsval* vp) { CallArgs args = CallArgsFromVp(argc, vp); fprintf(gOutFile, "built on %s at %s\n", __DATE__, __TIME__); args.rval().setUndefined(); return true; } This prevents reproducible builds. Is there a reason this is needed instead of using the buildid we're using for everything else?

Looks like dead code to me. https://dxr.mozilla.org/mozilla-central/search?q=regexp%3A\WBuildDate

It's exposed to JS as a build() function.

And does anyone call it?

js.cpp has the same code, too.

Come to think of it, the usefulness of these functions is questionable: they don't even return anything, they only print out the build time. Which in itself is not exactly a useful information. Is it a build of code from that day, or a later build of older code? How about removing this entirely? ni? bholley for xpcshell and jorendorf for js shell.

Happy to get rid of it if it doesn't break anything.

Comment on attachment 8610922 [details] [diff] [review] Remove build() function from js and xpc shells Review of attachment 8610922 [details] [diff] [review]: ----------------------------------------------------------------- I guess this might be useful if you have an xpcshell binary sitting around and want to know how old it is? I guess that still doesn't tell you all that much.

The file date is presumably giving as much information :)

Comment on attachment 8610922 [details] [diff] [review] Remove build() function from js and xpc shells Review of attachment 8610922 [details] [diff] [review]: ----------------------------------------------------------------- Stealing review as per request on IRC.