> >> __syscall_slong_t is a Linux specific type. We
> >> can add tv_nsec_t, which should be the same
> >> as time_t for all the current targets.
> >
> > Introducing tv_nsec_t looks reasonable to me.
> >
>
> Can you make the change?
>
> Thanks.
Not right now, I have lots of other things to do.
On Mon, Nov 18, 2013 at 6:17 AM, Arnaud Charlet wrote:
>> >
>> > type timespec is record
>> >tv_sec : time_t;
>> > - tv_nsec : long;
>> > + tv_nsec : time_t;
>> > end record;
>> > pragma Convention (C, timespec);
>> >
>> > But I'd rather settle on which type is appr
> Ada was using long for time_t and
>
> type timeval is array (1 .. 2) of C.long
>
> It assumes that the type of tv_nsec is the same as tv_sec.
Yes, and that was indeed wrong/dangerous.
> > --- s-osinte-solaris-posix.ads (revision 298928)
> > +++ s-osinte-solaris-posix.ads (working copy)
> >
On Mon, Nov 18, 2013 at 5:57 AM, Arnaud Charlet wrote:
>> >> struct timespec {
>> >> __kernel_time_t tv_sec; /* seconds */
>> >> longtv_nsec;/* nanoseconds */
>> >> };
>>
>> This is wrong for x32 where tv_nsec is long long, not
>> long.
> >> struct timespec {
> >> __kernel_time_t tv_sec; /* seconds */
> >> longtv_nsec;/* nanoseconds */
> >> };
>
> This is wrong for x32 where tv_nsec is long long, not
> long. There are a couple places where long should be
> long long for
On Mon, Nov 18, 2013 at 1:02 AM, Arnaud Charlet wrote:
>> Actually there are two issues with your change:
>>
>> Using time_t for tv_nsec looks actually wrong, the definition on (my)
>> linux is:
>>
>> struct timespec {
>> __kernel_time_t tv_sec; /* seconds */
>> lon
> Actually there are two issues with your change:
>
> Using time_t for tv_nsec looks actually wrong, the definition on (my)
> linux is:
>
> struct timespec {
> __kernel_time_t tv_sec; /* seconds */
> longtv_nsec;/* nanoseconds */
> };
>
> Yes, it passed all tests with -m32, -mx32, -m64 on Linux/x86-64.
> Installed on trunk. Is this OK to backport to 4.8 branch after
> a few days?
Actually there are two issues with your change:
Using time_t for tv_nsec looks actually wrong, the definition on (my)
linux is:
struct timespec {
> Yes, it passed all tests with -m32, -mx32, -m64 on Linux/x86-64.
> Installed on trunk. Is this OK to backport to 4.8 branch after
> a few days?
I would wait one or two weeks, to let time for people to report build
failures on other configs which is always possible when doing this kind of
delicat
On Fri, Nov 15, 2013 at 3:56 AM, Arnaud Charlet wrote:
>> Here is the new patch. Does it look OK?
>
> Assuming you can successfully build on e.g. x86-linux and x32-linux, this
> looks OK to me, thanks for your efforts!
>
Yes, it passed all tests with -m32, -mx32, -m64 on Linux/x86-64.
Installed
> Here is the new patch. Does it look OK?
Assuming you can successfully build on e.g. x86-linux and x32-linux, this
looks OK to me, thanks for your efforts!
Arno
On Fri, Nov 15, 2013 at 3:38 AM, Arnaud Charlet wrote:
>> > Looks better now, but please do not add a dependency on System.Linux in
>> > s-taprop-linux.adb, and instead use:
>> >
>> > type timeval is array (1 .. 2) of System.OS_Interface.time_t;
>> >
>> > Arno
>>
>> It doesn't work:
>>
>> s-ta
> > Looks better now, but please do not add a dependency on System.Linux in
> > s-taprop-linux.adb, and instead use:
> >
> > type timeval is array (1 .. 2) of System.OS_Interface.time_t;
> >
> > Arno
>
> It doesn't work:
>
> s-taprop.adb:630:60: "time_t" is not a visible entity of "OS_Interfa
On Fri, Nov 15, 2013 at 3:18 AM, Arnaud Charlet wrote:
> Looks better now, but please do not add a dependency on System.Linux in
> s-taprop-linux.adb, and instead use:
>
> type timeval is array (1 .. 2) of System.OS_Interface.time_t;
>
> Arno
It doesn't work:
s-taprop.adb:630:60: "time_t" is
Looks better now, but please do not add a dependency on System.Linux in
s-taprop-linux.adb, and instead use:
type timeval is array (1 .. 2) of System.OS_Interface.time_t;
Arno
On Fri, Nov 15, 2013 at 2:50 AM, Arnaud Charlet wrote:
>> >> This is what I got. I added s-posix-time.ads which declares
>> >> System.OS_Time.time_t. I use it instead long for time_t. I
>> >> didn't add time_t to s-linux.ads since it isn't used by
>> >> s-osprim-posix.adb.
>> >
>> > Adding s-po
> >> This is what I got. I added s-posix-time.ads which declares
> >> System.OS_Time.time_t. I use it instead long for time_t. I
> >> didn't add time_t to s-linux.ads since it isn't used by
> >> s-osprim-posix.adb.
> >
> > Adding s-posix-time.ads isn't desirable, too intrusive.
> > Better to use
On Fri, Nov 15, 2013 at 2:11 AM, Arnaud Charlet wrote:
>> This is what I got. I added s-posix-time.ads which declares
>> System.OS_Time.time_t. I use it instead long for time_t. I
>> didn't add time_t to s-linux.ads since it isn't used by
>> s-osprim-posix.adb.
>
> Adding s-posix-time.ads isn't
> This is what I got. I added s-posix-time.ads which declares
> System.OS_Time.time_t. I use it instead long for time_t. I
> didn't add time_t to s-linux.ads since it isn't used by
> s-osprim-posix.adb.
Adding s-posix-time.ads isn't desirable, too intrusive.
Better to use time_t (only) from sys
On Thu, Nov 14, 2013 at 1:16 PM, H.J. Lu wrote:
> On Thu, Nov 14, 2013 at 6:16 AM, Arnaud Charlet wrote:
>>> I also changed s-osinte-posix.adb and s-osprim-posix.adb
>>> for x32. They aren't Linux specific. What should I do with
>>> them?
>>
>> I would use the time_t type defined in s-osinte* (
On Thu, Nov 14, 2013 at 6:16 AM, Arnaud Charlet wrote:
>> I also changed s-osinte-posix.adb and s-osprim-posix.adb
>> for x32. They aren't Linux specific. What should I do with
>> them?
>
> I would use the time_t type defined in s-osinte* (all POSIX implementations
> of s-osinte* have such defin
On Thu, Nov 14, 2013 at 6:16 AM, Arnaud Charlet wrote:
>> I also changed s-osinte-posix.adb and s-osprim-posix.adb
>> for x32. They aren't Linux specific. What should I do with
>> them?
>
> I would use the time_t type defined in s-osinte* (all POSIX implementations
> of s-osinte* have such defin
> I also changed s-osinte-posix.adb and s-osprim-posix.adb
> for x32. They aren't Linux specific. What should I do with
> them?
I would use the time_t type defined in s-osinte* (all POSIX implementations
of s-osinte* have such definition, or if they don't, it's easy to add), and
in the s-osinte-
On Thu, Nov 14, 2013 at 2:30 AM, Arnaud Charlet wrote:
>> >> I am not familiar with Ada. Can you recommend how to fix it?
>> >
>> > Can you send a diff between the *-linux files and your new files? This
>> > should help giving some options.
>> >
>>
>> This is the total diff.
>
> OK so I would dec
> >> I am not familiar with Ada. Can you recommend how to fix it?
> >
> > Can you send a diff between the *-linux files and your new files? This
> > should help giving some options.
> >
>
> This is the total diff.
OK so I would declare a new type in System.Linux (e.g. time_t),
have a new varian
On Thu, Nov 14, 2013 at 2:02 AM, Arnaud Charlet wrote:
>> > No, introducing all these extra/almost duplicated files is not OK, you'd
>> > need to find a way to share the existing files instead, thanks.
>>
>> I am not familiar with Ada. Can you recommend how to fix it?
>
> Can you send a diff betw
> > No, introducing all these extra/almost duplicated files is not OK, you'd
> > need to find a way to share the existing files instead, thanks.
>
> I am not familiar with Ada. Can you recommend how to fix it?
Can you send a diff between the *-linux files and your new files? This
should help giv
On Thu, Nov 14, 2013 at 12:38 AM, Arnaud Charlet wrote:
>> FAIL: gnat.dg/memtrap.adb (test for excess errors)
>> FAIL: gnat.dg/memtrap.adb scan-assembler
>> __gnat_begin_handler|__gnat_raise_nodefer
>> FAIL: gnat.dg/specs/addr1.ads (test for bogus messages, line 24)
>> FAIL: gnat.dg/specs/atomic1
> FAIL: gnat.dg/memtrap.adb (test for excess errors)
> FAIL: gnat.dg/memtrap.adb scan-assembler
> __gnat_begin_handler|__gnat_raise_nodefer
> FAIL: gnat.dg/specs/addr1.ads (test for bogus messages, line 24)
> FAIL: gnat.dg/specs/atomic1.ads (test for errors, line 9)
> FAIL: gnat.dg/specs/atomic1.
29 matches
Mail list logo
