This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Avoid collisions between parallel installations of Cygwin


Charles Wilson wrote:
> Coinna wrote:
>> On Oct 21 05:59, Eric Blake wrote:

  ^^^^ oops. I should have sniped this header line. Corinna wrote all of
       the stuff immedately below.
>> Nice.  I created a simple shell script which can do the job.  It even
>> allows to replace the cygwin1.dll in /bin on the fly.  My script name of
>> choice is "enable-unique-object-names":
>>
>>   $ enable-unique-object-names
>>   Usage: enable-unique-object-names [show|yes|no] [path-to-cygwin-DLL]
>>   $ enable-unique-object-names show
>>   Default to /bin/cygwin1.dll
>>   yes
>>   $ enable-unique-object-names no
>>   $ enable-unique-object-names show
>>   Default to /bin/cygwin1.dll
>>   no
>>
>> Do you think this is sufficient for now?
> 
> Unfortunately, I don't.

I take it back.  It's okay: BUT I think you should stick with your
original plan of using data in the following self-documenting struct:

struct resource_value
{
#if !defined(CHUCK)
  char name[32];
  char description[220];
  unsigned long value;
#elif
  char name[32];
  char description[200];
  unsigned long type; /* enum: ulong, etc */
  union
  {
    unsigned long ul_value;
    signed long   sl_value;
    double         d_value; /* does this need to be 8-aligned? */
    char[20]       s_value;
  } value;
#endif
};

(whether you use instead wchar_t* and L"" strings is up to you).

because of this:

> ...unless the magic ID strings themselves were also each part of the
> struct.  In THAT case, I suppose the offsets between beginning of the
> string and the data would depend only on the length of the string, the
> packing options (-ms-struct?, pragma pack?) used during the compile, and
> the specific alignment requirements of the data -- none of which would
> change.

The only requirement would be that each name[32] must be globally
unique...but how can it be, if the reader code *in* cygwin must do
  for (p = beginP; p->name != NULL; p++)
    if (strcmp(p->name, "SUPPOSEDLY_UNIQUE_STR"))
      set value based on p->value
??

Well, this way: require that actual name[] values stored on-disk begin
with "$$", but always do the comparisons this way:

   if (strcmp(&(p->name[2]), "SUPPOSEDLY_UNIQUE_STR"))

(I know, I'm glossing over some error-checking for OOB memory access)

Then, the external tool can look for "$$SUPPOSEDLY_UNIQUE_STR" and not
get any false positives (I use '$' because they won't accidentally show
up in symbol names, if anybody ever does

SUPPOSEDLY_UNIQUE_STR(void)
{
}

(which isn't a bad idea for encapsulating access to the value, for use
from other locations in cygwin)

> This isn't a concern for the
> Windows on-disk registry which uses that scheme, but ours requires
> swapped-in RAM storage.

Meh. The original self-documenting proposal was going to do this anyway,
and there aren't really going to be a whole lot of these. One, to start
with.

> but is it wise, this
> "close" to the release, to send the XDR cat after the Mutable mouse
> after the .rsrc spider after the disable-unique-object-names fly?

No, it isn't.  I vote for a modifier-script (or program, maybe even
still cygcheck), that "knows" about the offset WITHIN the (packed) struct of

struct resource_value
{
  char name[32];
  ...
  <important stuff>
}

from name[] to <important stuff>.

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]