Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2001:
[Freeciv-Dev] Re: Client Side Translation
Home

[Freeciv-Dev] Re: Client Side Translation

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Client Side Translation
From: Michael Stefaniuc <mstefani@xxxxxxxxx>
Date: Wed, 31 Oct 2001 15:03:14 +0100

On Wed, Oct 31, 2001 at 02:42:39PM +0100, Raimar Falke wrote:
> On Wed, Oct 31, 2001 at 12:58:01PM +0100, Michael Stefaniuc wrote:
> > > > > follow. put_uchar_vec should be put_mem (similar to strcpy vs memcpy).
> > > > Hmm ... I don't know if it's a good idea because put_uchar_vec
> > > > serializes only an array of unsigned chars and not random memory (don't
> > > > want to tempt anybody to use it to serialize something else than an
> > > > array of chars like e.g. a struct). 
> > > 
> > > Why is this/can turn into a problem?
> > Using the struct as examble: the members of a struct can be differently
> > alligned on different OS'es/archs; an int/float can be a member of a
> > struct and therefor we get problems with the endianess.
> > And  put_uchar_vec isn't similar to memcpy: memcpy takes as src
> > a void pointer whereas put_uchar_vec uses unsigned char.
> 
> I meant that string (str* methods) are null terminated and memory
> (mem* functions) are specified by their length. It looks to me that
> put_uchar_vec is such a memory function.
From that standpoint you are right. I don't mind to much how the functions
are named so I will rename put_uchar_vec to put_mem.

bye
        michael
-- 
Michael Stefaniuc               Tel.: +49-711-96437-199
System Administration           Fax.: +49-711-96437-111
Red Hat GmbH                    Email: mstefani@xxxxxxxxx
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart


[Prev in Thread] Current Thread [Next in Thread]