On Thu, 15 Feb 2007, Pascal Hofstee wrote:
On Thu, 2007-02-15 at 13:41 +, Robert Watson wrote:
Unfortunately, things are a bit more tricky. The problem is not so much
the API, where converting size_t/int is a relative non-event, rather, the
ABI. By changing the size of a field in a data
On Thu, 2007-02-15 at 13:41 +, Robert Watson wrote:
> Unfortunately, things are a bit more tricky. The problem is not so much the
> API, where converting size_t/int is a relative non-event, rather, the ABI.
> By
> changing the size of a field in a data structure, you may change the layout
On Thu, 15 Feb 2007, Pascal Hofstee wrote:
On 1/31/07, Robert Watson <[EMAIL PROTECTED]> wrote:
If we do decide to go ahead with the ABI change, there are a number of
other things that should be done simultaneously, such as changing the uid
and gid fields to uid_t and gid_t. I would very much
On 1/31/07, Robert Watson <[EMAIL PROTECTED]> wrote:
If we do decide to go ahead with the ABI change, there are a number of other
things that should be done simultaneously, such as changing the uid and gid
fields to uid_t and gid_t. I would very much like to see the ABI change
happen, and the fi
"M. Warner Losh" <[EMAIL PROTECTED]> wrote:
> In message: <[EMAIL PROTECTED]>
> Fabian Keil <[EMAIL PROTECTED]> writes:
> : Robert Watson <[EMAIL PROTECTED]> wrote:
> : > If we do decide to go ahead with the ABI change, there are a number of
> other
> : > things that should be done
In message: <[EMAIL PROTECTED]>
Fabian Keil <[EMAIL PROTECTED]> writes:
: Robert Watson <[EMAIL PROTECTED]> wrote:
:
: > On Wed, 31 Jan 2007, Dag-Erling Smørgrav wrote:
: >
: > > Pascal Hofstee <[EMAIL PROTECTED]> writes:
: > >> Any additional sugestions/objections are always greatly
On Wed, 2007-Jan-31 10:52:02 +, Robert Watson wrote:
>If we do decide to go ahead with the ABI change, there are a number of
>other things that should be done simultaneously, such as changing the uid
>and gid fields to uid_t and gid_t.
And mode to mode_t. The uid and gid fields in struct sh
Robert Watson <[EMAIL PROTECTED]> wrote:
> On Wed, 31 Jan 2007, Dag-Erling Smørgrav wrote:
>
> > Pascal Hofstee <[EMAIL PROTECTED]> writes:
> >> Any additional sugestions/objections are always greatly appreciated.
> >
> > On 32-bit platforms (i386, powerpc), int is a 32-bit signed integer while
On Wed, 31 Jan 2007, Dag-Erling Smørgrav wrote:
Pascal Hofstee <[EMAIL PROTECTED]> writes:
Any additional sugestions/objections are always greatly appreciated.
On 32-bit platforms (i386, powerpc), int is a 32-bit signed integer while
size_t is a 32-bit unsigned integer.
On 64-bit platform
Pascal Hofstee <[EMAIL PROTECTED]> writes:
> Any additional sugestions/objections are always greatly appreciated.
On 32-bit platforms (i386, powerpc), int is a 32-bit signed integer
while size_t is a 32-bit unsigned integer.
On 64-bit platforms (amd64, sparc64 etc), int is a 32-bit signed
integer
Peter Jeremy wrote:
Whilst I agree that the Linux defn is the more sensible one, System V
IPC and common sense are not commonly found together. Tradionally the
definition was "int". It appears that the definition changed from
"int" to "size_t" in issue 5 of the Open Group base definition but
Fr
On Wed, 2007-Jan-31 08:30:27 +0100, Pascal Hofstee wrote:
>In a recent attempt in trying to clean up some compiler warnings in a
>GNUstep related project i came upon a case where the FreeBSD datatypes
>seemed to disagree with the Linux ones. Though this in itself is not
>unusual i do wonder if i
Hi,
In a recent attempt in trying to clean up some compiler warnings in a
GNUstep related project i came upon a case where the FreeBSD datatypes
seemed to disagree with the Linux ones. Though this in itself is not
unusual i do wonder if in this case the Linux definition isn't the more
proper
13 matches
Mail list logo
