I'm not sure I understand what you mean by "exported". Does is mean that if a function is *exported*, it's visible to the user.. If so is it reasonable to be used for any sort of list management or (2) should we enforce that those functions are to be used only in conjunction with the code in shmem.c ?.. If (2), then why *export* the functions ?..
Thx -Madhu -----Original Message----- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2001 12:16 PM To: [email protected] Subject: Fw: [PATCH] shmem.c - 3rd try ----- Original Message ----- From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 24, 2001 2:15 PM Subject: Re: [PATCH] shmem.c - 3rd try > From: "Ryan Bloom" <[EMAIL PROTECTED]> > Sent: Monday, September 24, 2001 1:54 PM > > > > On Monday 24 September 2001 11:27 am, 'Justin Erenkrantz' wrote: > > > If at some later point we decide that we should split it we can. > > > You typically want to split the files when something else may use > > > these functions (i.e. they are exported) - that isn't the case here. > > > For now, the helper functions should be declared as static (which > > > means they need to be in the same compilation unit) - otherwise we > > > get into namespace issues (i.e. must be prefixed by apr_). -- justin > > > > I want those functions exported, because they can be used by any platform > > to create the shared memory list. This makes porting to Windows much easier > > than it will be if I have to re-write all of the list functions. > > There is a difference (on Win32, at least) between 'exported'. > That is, without APR_DECLARE_FOO, the function name isn't exported from > the shared library. > > In any case, if these are flexible helpers, why not follow the model we > used for network_io shared code? That seemed to work fairly well. >
