Re: [libposix-development] Initial source code release

[Henrique A. <hd...@gm...>]

2009/6/1 Andreas Krennmair <akr...@go...>:
> Hi,
> On Mon, Jun 1, 2009 at 6:48 PM, Henrique Almeida <hd...@gm...> wrote:
>>
>> > How are patches supposed to be submitted? I have two patches ready, one
>>
>>  Either join the project and get write access to the repository, or
>> just paste them into the mailing list. ;-)
>
> OK, I'll stick with posting them here so far. It's always good to have an
> explicit review process.
>
>>
>>  Thanks for the patches, I've uploaded them to the repository. Notice,
>> however, that 1) runtime support (init.o and others) is not linked
>> into libposix, only in the final application (maybe we should separate
>> the runtime source
>
> Alright.
>
>>
>> ?) 2) size_t is unsigned, so the decrement in the
>> loops are invoking undefined behavior (maybe a simpler, positive loop
>> will do, the compiler will optimize that anyway).
>
> I'm aware of that, and the code is safe: expression such as
>     while (size--) {
> are totally fine: in case size is 0, the expression size-- returns 0, which
> makes the while-loop terminate, and _then_ size is decremented. The value of
> size is undefined afterwards, but it isn't used anymore afterwards, anyway,
> in none of my submitted routines, so I see no problem with the code.

 Undefined behavior is more general than that. A processor may, for
example, trap on integer overflow (or a compiler can insert code to do
this). Anyway, I've just found out that unsigned integer arithmetic
has DEFINED modular behavior. My bad, sorry. I think a remark
suffices: keep the code as safe as possible.

>
>>
>>   The next tasks will be the inclusion of unit testing and porting
>> hello world to more platforms.
>
> I've been playing around a bit with an x86_64 port, but since I'm not an
> expert on assembler (especially x86_64), I didn't have much luck getting
> link my attempt of it. My last guess was that I'd need to have position
> independent code, but then I accidently typed in "git stash drop" instead of
> "git stash pop" and removed my work on that topic. :-/

 If we're lucky, x86_64 uses "syscall" directly instead of vsyscall.
We must find out how system calls work in x86_64 (hint: post here the
output of "ldd /bin/ls" from a x86_64 distribution). If necessary,
examples on how to deal with PIC code (and more) are on the ABI
document:

 http://www.x86-64.org/documentation/abi.pdf

 The assembly code for x86 (_start.asm and syscalls.asm) is not
suitable for x86_64.

>
> Regards,
> Andreas
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Libposix-development mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libposix-development
>
>



-- 
 Henrique Dante de Almeida
 hd...@gm...