Re: [PLUG] Mac OS/X, Darwin and Opensource software...

["Kyle R . Burton" <mortis@voicenet.com>]

> > compiler errored on code that assigned the output of memcpy() to a pointer
> > variable.
> 
> So cast it.
> 
> (Without a more specific description of the problem, I can't give a
> more specific answer than that.)

The errors this user reported were:

  localealias.c: In function `read_alias_file':
  localealias.c:351: void value not ignored as it ought to be
  localealias.c:355: void value not ignored as it ought to be

Which leads me to beleive that memcpy is prototyped as:

   void memcpy(void*,void*,size_t)

on his system, it's prototyped as:

   void* memcpy(void*,void*,size_t)

On my Linux system (and everywhere else that I know of).  The lines in 
question are:

    map[nmap].alias = memcpy (&string_space[string_space_act], /* 351 */
      alias, alias_len);
    string_space_act += alias_len;

    map[nmap].value = memcpy (&string_space[string_space_act], /* 355 */
      value, value_len);
    string_space_act += value_len;

map.alias and map.value are both of type char*.  I know that those lines 
should read:

    map[nmap].alias = (char*)memcpy (&string_space[string_space_act],
      alias, alias_len);
    string_space_act += alias_len;

    map[nmap].value = (char*)memcpy (&string_space[string_space_act],
      value, value_len);
    string_space_act += value_len;

to be completely correct, but autoconf/gcc does build the software 
successfuly under a bunch of different systems (including Linux, HP-UX, 
Solaris, and some of the BSDs), and without warnings on most if not
all of these systems AFAIK.  Besides, assigning a void* to a char* varaible
should generate a casting warning, not an error, and not the error 
reported above.  Unless my knowledge of C and gcc have decayed (which is
possible, I have hit the renewal age [Logan's Run] after all :).

> Default autoconf setup takes --with-{c,cpp,ld}flags arguments. Isn't
> that enough?

It probably is.  I just hadn't suggested it to him.  Thanks.

> Hardcoding some weird-ass vendor's paths into your configure script
> isn't such a great idea, especially since they tend to move them
> around.
> 
> If you're going to do this, though, you might consider also
> accounting for /opt on SysV-style systems, /usr/pkg on NetBSD (and
> BSD/OS? and OpenBSD?) systems, /usr/port on FreeBSD systems(?)...
> there's yet another path that Tru 64 uses, but I don't have access
> to any Tru 64 systems at the moment to check.

I'd like the software to build as easily as possible on as many
systems as possible.  Using the configure switches you mentioned are
probably the best solution.


Thanks,
Kyle



-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mortis@voicenet.com                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

______________________________________________________________________
Philadelphia Linux Users Group       -      http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion  -  http://lists.phillylinux.org/mail/listinfo/plug