Alban,
The reference for strncpy states:
"Copies the first num characters of source to destination. If the end
of the source C string (which is signaled by a null-character) is
found before num characters have been copied, destination is padded
with zeros until a total of num characters have been written to it."
Thus the string should automatically be 0 padded.
I was going to just do it byte-by-byte, but then that would likely
have overcomplicated the code.
With regards to ^=, i can't seem to find a binary not operator, only a
logical not operator. So xor with 0xFF is a suitable alternative -
which is what actually what ScummVM does too.
Regards,
James S Urquhart
On 9/14/07, Alban Bedel <[EMAIL PROTECTED]> wrote:
> On Thu, 13 Sep 2007 23:01:54 +0100
> James Urquhart <[EMAIL PROTECTED]> wrote:
>
> > Hey again,
> >
> > After looking at the linker code, i noticed that a dummy RNAM (room
> > names) chunk was being written in the index file. From what i can
> > tell, the room names are omitted from more or less all V6+ games (i
> > guess either the developers didn't want people finding the end game
> > room, or maybe it was just a space saving initiative).
> >
> > In any case, the attached patch should add support for writing RNAM
> > chunks provided you pass the along "-write-room-names" to the linker
> > when building.
>
> Nice :)
>
> > Note that i don't know if all LEC interpreters will read this chunk
> > data correctly as there is always the possibility that the format was
> > changed between V5 and V8 - something which SCUMM hackers are
> > unlikely to track if the data isn't present in the first place.
>
> As long as the LEC interpreter still load the games that should be
> enouth for now.
>
> > + for (r = room ; r ; r = r->next)
> > + {
> > + scc_fd_w8(fd, r->sym->addr);
> > + strncpy(rnam_buf, r->sym->sym, 9);
> > + for (i=0; i<10; i++)
> > + rnam_buf[i] ^= 0xFF;
> > + scc_fd_write(fd, rnam_buf, 9);
> > + }
>
> If the name is less than 9 chars long the rest must be completly filled
> with 0. Otherwise it could in some cases lead to different output with
> the same input and that would break the tests.
>
> BTW ^= 0xFF is just a binary not, and you can definitly spare the array,
> just writing char by char is not going to make any big speed difference.
> But that's just taste, as long as it work do as you please :)
>
> Albeu
>
>
> _______________________________________________
> ScummC-general mailing list
> [email protected]
> https://mail.gna.org/listinfo/scummc-general
>
_______________________________________________
ScummC-general mailing list
[email protected]
https://mail.gna.org/listinfo/scummc-general