Make all NSPR symbols "private extern"

Make all NSPR symbols "private extern".

BUG=24911
TEST=mac$ nm C.app/Contents/Versions/*/C F.framework/C F | grep " [A-TV-Z] "
     should not show any NSPR symbols.  The following NSPR symbols were
     formerly exported:
     __Z14PR_ImplodeTimePK14PRExplodedTime
     __Z16PR_GMTParametersPK14PRExplodedTime
     __Z16PR_NormalizeTimeP14PRExplodedTimePF16PRTimeParametersPKS_E
     __Z18PR_ParseTimeStringPKciPx
     These symbols should no longer be exported on any platform.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=29182

[Mark Mentovai, 2009-10-15 20:27:55]

I meant to send this out for review earlier but the tree exploded.

[wtc, 2009-10-15 20:48:31]

LGTM.  Thanks a lot!

http://codereview.chromium.org/274068/diff/1/2
File base/third_party/nspr/prtypes.h (right):

http://codereview.chromium.org/274068/diff/1/2#newcode101
Line 101: #define PR_EXPORT(__type) extern __type
Please use 'extern' on all four macros in this section.
See the Unix definition at lines 237-240.

[wtc, 2009-10-15 20:49:15]

http://codereview.chromium.org/274068/diff/1/2
File base/third_party/nspr/prtypes.h (right):

http://codereview.chromium.org/274068/diff/1/2#newcode94
Line 94: ** Chrome-local change: the portions of NSPR used for Chrome are
Nit: Should we use "Chromium" instead of "Chrome" in this
comment block?

[Mark Mentovai, 2009-10-15 20:52:12]

http://dev.chromium.org/developers/coding-style says:

"Chromium" is the name of the project, not the product, and should never appear
in code in variable names, API names etc. Use "chrome" instead.

I usually try to avoid the whole mess by writing "the application" or "this
module," but this seemed to be the rare case where we needed to refer to
something by proper name.  If you've got suggestions on how to word it better,
I'm all ears.

[wtc, 2009-10-16 18:34:57]

On 2009/10/15 20:52:12, Mark Mentovai wrote:
> http://dev.chromium.org/developers/coding-style says:
> 
> "Chromium" is the name of the project, not the product, and should never
appear
> in code in variable names, API names etc. Use "chrome" instead.

But this is source code comment, not variable or API ames.  Our
license header also says "Chromium Authors".  How about if we just
say "the base module" as opposed to "Chrome's net module", etc.

I tried to verify your fix on Windows.  For some reason, Windows
doesn't need this change.  Here is the symbols exported from
chrome.dll before this change.  Only the Hunspell symbols are
accidentally exported:

D:\chrome1\src\chrome\Debug>dumpbin /exports chrome.dll
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file chrome.dll

File Type: DLL

  Section contains the following exports for chrome.dll

    00000000 characteristics
    4AD8B1EB time date stamp Fri Oct 16 10:48:27 2009
        0.00 version
           1 ordinal base
          13 number of functions
          13 number of names

    ordinal hint RVA      name

          1    0 00001140 ChromeMain = @ILT+315(_ChromeMain)
          2    1 018FD970 Hunspell_add = _Hunspell_add
          3    2 018FD990 Hunspell_add_with_affix = _Hunspell_add_with_affix
          4    3 018FD8C0 Hunspell_analyze = _Hunspell_analyze
          5    4 018FD7F0 Hunspell_create_key = _Hunspell_create_key
          6    5 018FD800 Hunspell_destroy = _Hunspell_destroy
          7    6 018FD9D0 Hunspell_free_list = _Hunspell_free_list
          8    7 018FD920 Hunspell_generate = _Hunspell_generate
          9    8 018FD880 Hunspell_get_dic_encoding = _Hunspell_get_dic_encoding

         10    9 018FD9B0 Hunspell_remove = _Hunspell_remove
         11    A 018FD860 Hunspell_spell = _Hunspell_spell
         12    B 018FD8E0 Hunspell_stem = _Hunspell_stem
         13    C 018FD8A0 Hunspell_suggest = _Hunspell_suggest

  Summary

       F6000 .data
        2000 .didat
        6000 .idata
     2414000 .rdata
      14C000 .reloc
      121000 .rsrc
     2A0F000 .text
        1000 .tls
        1000 .unwante

[wtc, 2009-10-16 18:38:31]

I found out why...

I or someone else must have removed __declspec(dllexport)
from the definition of PR_IMPLEMENT for WIN32 before.