[gccsdk] [Bug 249] New: GCC 4.7.4 Rel 1 Dev 2014-01-08: mktime() returns wrong value
http://www.riscos.info/bugzilla3/show_bug.cgi?id=249
Summary: GCC 4.7.4 Rel 1 Dev 2014-01-08: mktime() returns wrong
value
Product: GCC/GCCSDK
Version: other
Platform: Other
OS/Version: RISC OS
Status: NEW
Severity: normal
Priority: P1
Component: C compiler
AssignedTo: john.tyt...@aaug.net
ReportedBy: duncan.mo...@gmx.com
Estimated Hours: 0.0
GCCSDK GCC 4.7.4 Release 1 Development 4.7.4 2014-01-08
http://www.riscos.info/downloads/gccsdk/testing/4.7.4/gccsdk-gcc-bin-4.7.4-Rel1dev.zip
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39
This program prints an elapsed time using mktime().
Under gcc 4.1.2 it gives what I'd expect:
946684799
Under gcc 4.7.4 it gets it wrong. After recompiling it gets it wrong in the
same way. After rebooting it gets it wrong in a different way. Here's some of
the values it gives after rebooting:
1633879566
-1973892963
-943100812
-771302120
-1114899504
87691339
They appear to differ from the correct value by simple fractions of 2^30, e.g.:
0.64*2^30
1.92*2^30
gcc err_mktime.c
#include stdio.h
#include time.h
int main(void) {
struct tm tm;
tm.tm_sec = 59;
tm.tm_min = 59;
tm.tm_hour = 23;
tm.tm_mday = 31;
tm.tm_mon = 11;
tm.tm_year = 99;
tm.tm_isdst = -1;
time_t t = mktime (tm);
printf(%li\n,t);
return 0;
}
--
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all bug changes.
___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] GCC 4.7.4 Rel 1 Dev 2014-01-08: Text file execute permission bit
GCCSDK GCC 4.7.4 Release 1 Development 4.7.4 2014-01-08
http://www.riscos.info/downloads/gccsdk/testing/4.7.4/gccsdk-gcc-bin-4.7.4-Rel1dev.zip
SharedUnixLibrary 1.12
VirtualRPC-Adjust RISCOS 4.39
The execute permission bit for Text files has changed to be the same as
for other filetypes. So the program below under gcc 4.1.2 gives:
Obey xxx
Text ---
and under gcc 4.7.4 gives:
Obey xxx
Text xxx
Was this change intentional? And will it stay like this, or be reverted
to the 4.1.2 behaviour? (It affects some of my regression tests).
#include stdio.h
#include stdlib.h
#include sys/stat.h
static void prot(const char* filename,const char* cmd) {
system(cmd);
struct stat s;
stat(filename,s);
printf(%s %c%c%c\n,cmd[17],
(s.st_mode S_IXUSR ? 'x' : '-'),
(s.st_mode S_IXGRP ? 'x' : '-'),
(s.st_mode S_IXOTH ? 'x' : '-'));
}
int main(void) {
system(Echo abc { testfile });
prot(testfile,SetType testfile Obey);
prot(testfile,SetType testfile Text);
system(Delete testfile);
return 0;
}
Regards
Duncan
___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] fgets problem/Unixlib
In message 53185d39.9090...@sky.com Lee Noar leen...@sky.com wrote: On 05/03/14 21:41, Theo Markettos wrote: On Wed, Mar 05, 2014 at 08:06:57PM +, Lee Noar wrote: I tried the test binaries, both dynamic and static, with RISC OS running in rpcemu. They both worked as expected. When you say that there is an infinite loop, do you get: As a warning, UnixLib's behaviour is quite sensitive to the underlying filing system. I have a port of git, which doesn't work due to filename issues. It turns out it has completely different filename issues on RAMFS and HostFS on rpcemu (0.8.9 Mac, RO5.21 of recent vintage). I haven't followed everything through to work out the full details, but the final error (from git-add) that happens on HostFS is it tries to open() a file in a nonexistent directory. git's code will look for ENOENT, backtrack, create the directory and try again. On RAMFS this works OK (the code later falls over elsewhere). On HostFS open() returns EOPSYS, the git error checking code doesn't know what to do with this, and so falls over. HostFS is returning a different error from FileCore, UnixLib isn't matching on that, and so it returns a UnixLib-specific errno. So always worth testing on a range of filing systems, because behaviours can differ. EOPSYS is a RISC OS specific code for an operating system error which of course is not recognised by ported software. I think to avoid problems like you are having, open() should not be returning EOPSYS - it should only return one of the errors defined in the spec: http://linux.die.net/man/3/open I'll see if I can substitute more suitable codes. Normally EOPSYS is only returned as last resort. There is a lot of effort done to try to map RISC OS errors into proper errno error values but of course this assumes e.g. that filing systems do return their error numbers according to PRM 2-258. Roughly a year ago I did several UnixLib fixes for returning more accurate errno error values and made a small unittest framework (recipe/files/gcc/libunixlib/unittest) for testing these changes. It would be interesting to have those unittests run on HostFS instead of a FileCore based FS what I used at that time. My guess is that HostFS will fail more of those unittests... Aside, while writing this mail, I noticed that our mkdir() implementation could do a better RISC OS error number check, I've fixed that with r6620. John. -- John Tytgat, in his comfy chair at home john.tyt...@aaug.net ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] GCC 4.7.4 Rel 1 Dev 2014-01-08: Text file execute permission bit
In message 531b1ae9.9010...@gmx.com Duncan Moore duncan.mo...@gmx.com wrote: GCCSDK GCC 4.7.4 Release 1 Development 4.7.4 2014-01-08 http://www.riscos.info/downloads/gccsdk/testing/4.7.4/gccsdk-gcc-bin-4.7.4-Rel1dev.zip SharedUnixLibrary 1.12 VirtualRPC-Adjust RISCOS 4.39 The execute permission bit for Text files has changed to be the same as for other filetypes. So the program below under gcc 4.1.2 gives: Obey xxx Text --- and under gcc 4.7.4 gives: Obey xxx Text xxx Was this change intentional? And will it stay like this, or be reverted to the 4.1.2 behaviour? (It affects some of my regression tests). Not intentional. Setting the execute permission bit is done in common/attrib.c and the S_IEXEC bit is derived from RISC OS file attribute bit 2, this since r1302 (roughly 9 years ago). I presume this change is the result of the cleanups done for 4.7.x developments. I'm not sure using RISC OS file attribute bit 2 is for determinig execute permission bit is good. It is (was) used for BBC ADFS and privately for SJ Research file systems and further marked as possibly to be used for future expansion (if PRM 2-13 is to be believed). I think it would be better to derive this from RISC OS filetype, i.e. test on Obey, Absolute, ELF, Module, Utility (any others ?). Opinions ? John. -- John Tytgat, in his comfy chair at home john.tyt...@aaug.net ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] GCC 4.7.4 Rel 1 Dev 2014-01-08: Text file execute permission bit
John Tytgat john.tyt...@aaug.net wrote: I think it would be better to derive this from RISC OS filetype, i.e. test on Obey, Absolute, ELF, Module, Utility (any others ?). If you allowed Obey, why not BASIC? And then, why not Lua, REXX, Python etc - how would the code know whether to treat an arbitrary filetype as executable? -- Jeremy C B Nicoll - my opinions are my own. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] GCC 4.7.4 Rel 1 Dev 2014-01-08: Text file execute permission bit
In message mpro.n24muc00igub60...@wingsandbeaks.org.uk.invalid Jeremy Nicoll - ml roinfo jn.ml.roi...@wingsandbeaks.org.uk wrote: John Tytgat john.tyt...@aaug.net wrote: I think it would be better to derive this from RISC OS filetype, i.e. test on Obey, Absolute, ELF, Module, Utility (any others ?). If you allowed Obey, why not BASIC? And then, why not Lua, REXX, Python etc - how would the code know whether to treat an arbitrary filetype as executable? I currently can only come up with the pragmatic approach of using a set of filetypes to fake the execute permission bits. If we would go for it, a short list of filetypes is preferred so trying to limit it to those cases where it really matters. I think that's filetypes representing/containing ARM code but I admit that's very arbitrary. Your Obey filetype challenge is a good one, I'm not sure whether I can really justify that. Duncan, do you actually have usecases where the execute permission bits matter ? Is this an issue for a certain port ? Or is this just found by your testing ? I can only imagine this being an issue for a ported shell, like bash. John. -- John Tytgat, in his comfy chair at home john.tyt...@aaug.net ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] GCC 4.7.4 Rel 1 Dev 2014-01-08: Text file execute permission bit
On 08/03/2014 17:33, John Tytgat wrote: In message mpro.n24muc00igub60...@wingsandbeaks.org.uk.invalid Jeremy Nicoll - ml roinfo jn.ml.roi...@wingsandbeaks.org.uk wrote: John Tytgat john.tyt...@aaug.net wrote: I think it would be better to derive this from RISC OS filetype, i.e. test on Obey, Absolute, ELF, Module, Utility (any others ?). If you allowed Obey, why not BASIC? And then, why not Lua, REXX, Python etc - how would the code know whether to treat an arbitrary filetype as executable? I currently can only come up with the pragmatic approach of using a set of filetypes to fake the execute permission bits. If we would go for it, a short list of filetypes is preferred so trying to limit it to those cases where it really matters. I think that's filetypes representing/containing ARM code but I admit that's very arbitrary. Your Obey filetype challenge is a good one, I'm not sure whether I can really justify that. Duncan, do you actually have usecases where the execute permission bits matter ? Is this an issue for a certain port ? Or is this just found by your testing ? No, I have nothing where it matters - I just observed the change in some of my test cases. If the execute permission bit is going to be based on filetypes, then just using filetypes that have ARM code has the advantage that it's a relatively small (unambiguous?) set, and unlikely to change much in the future. Regards Duncan ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] GCC 4.7.4 Rel 1 Dev 2014-01-08: Text file execute permission bit
Hi John, I think it would be better to derive this from RISC OS filetype, i.e. test on Obey, Absolute, ELF, Module, Utility (any others?). If you allowed Obey, why not BASIC? And then, why not Lua, REXX, Python etc - how would the code know whether to treat an arbitrary filetype as executable? Waht about if there's a RunType variable defined for that filetype? My RISC OS memory is hazy but that might be an option. Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] fgets problem/Unixlib
On Sat, Mar 08, 2014 at 04:34:37PM +0100, John Tytgat wrote: Roughly a year ago I did several UnixLib fixes for returning more accurate errno error values and made a small unittest framework (recipe/files/gcc/libunixlib/unittest) for testing these changes. It would be interesting to have those unittests run on HostFS instead of a FileCore based FS what I used at that time. My guess is that HostFS will fail more of those unittests... Here you go. RPCEmu 0.8.9, RISC OS 5.20 (10 Jun 2013), Mac OS 10.9. It does fail a few... Theo *^.runme Test 'Test_001_BasicFileOpen'... ok Test 'Test_002_BasicDirOpen'... ok Test 'Test_003_FOpenAppend'... ok Test 'Test_004_SameFileOpenTwice'... ok Test 'Test_005_FileOpenViaSymLink'... ok Test 'Test_006_GenerationOfEINVAL'... ok Test 'Test_007_GenerationOfEFAULT'... ok Test 'Test_008_GenerationOfENOENT'... ok Test 'Test_009_GenerationELOOP'... ok Test 'Test_010_GenerationENAMETOOLONG'... ok All /HostFS:$/unittest/fopen tests were ok Test 'Test_001_BasicStat'... ok Test 'Test_003_GenerationOfEFAULT'... ok Test 'Test_004_GenerationOfELOOP'... ok Test 'Test_005_GenerationOfENOTDIR'... lstat(dir1/file2/object, ...) got error 2 (No such file or directory) while we would have expected error 20 (Not a directory) *** ExpectCall_LStat FAILED at line 203 ! *** Test 'Test_005_GenerationOfENOTDIR' FAILED ! Test 'Test_006_GenerationOfENOENT'... ok Test 'Test_007_GenerationOfENAMETOOLONG'... ok Test 'Test_001_BasicReadLink'... ok Test 'Test_002_BufSize'... ok Test 'Test_003_GenerationOfEINVAL'... ok Test 'Test_004_GenerationOfEFAULT'... ok Test 'Test_005_GenerationOfENOENT'... ok Test 'Test_006_GenerationOfENOTDIR'... readlink(dir1/file2/symlink, ..., 4) returned errno 2 (No such file or directory) but we expected errno 20 instead *** ExpectCall_ReadLink FAILED at line 159 ! *** Test 'Test_006_GenerationOfENOTDIR' FAILED ! Test 'Test_007_GenerationOfENAMETOOLONG'... ok Test 'Test_001_BasicRealPath'... ok Test 'Test_003_GenerationOfEINVAL'... ok Test 'Test_004_GenerationOfELOOP'... ok Test 'Test_005_GenerationOfENOENT'... ok Test 'Test_006_GenerationOfENOTDIR'... realpath(dir1/file2/object, NULL) returned a NULL value (errno 2 'No such file or directory') but we expected errno 20 'Not a directory' instead *** ExpectCall_RealPath FAILED at line 127 ! *** Test 'Test_006_GenerationOfENOTDIR' FAILED ! Test 'Test_001_BasicRenameFile'... ok Test 'Test_002_BasicRenameDir'... ok Test 'Test_003_BasicRenameSymLink'... ok Test 'Test_004_RenameFileAndDstExists'... ok Test 'Test_005_RenameDirAndDstExists'... ok Test 'Test_006_GenerationOfEISDIR'... ok Test 'Test_007_GenerationOfENOENT'... rename(file, dir/nodir/foo) got error 0 (Success) while we would have expected error 2 (No such file or directory) *** ExpectCall_Rename FAILED at line 243 ! *** Test 'Test_007_GenerationOfENOENT' FAILED ! Test 'Test_008_GenerationOfENOTDIR'... rename(file/nofile, other_file) got error 2 (No such file or directory) while we would have expected error 20 (Not a directory) *** ExpectCall_Rename FAILED at line 282 ! *** Test 'Test_008_GenerationOfENOTDIR' FAILED ! Test 'Test_009_GenerationOfEFAULT'... ok Test 'Test_010_GenerationOfEINVAL'... rename(dir, dir/subdir/foo) got error 88 (Bad rename) while we would have expected error 22 (Invalid argument) *** ExpectCall_Rename FAILED at line 340 ! *** Test 'Test_010_GenerationOfEINVAL' FAILED ! Test 'Test_011_GenerationOfENAMETOOLONG'... ok Test 'Test_012_RenameWithFiletypeSuffix'... ok Test 'Test_013_RenameWithExtension'... ok Test 'Test_001_BasicStat'... ok Test 'Test_003_GenerationOfEFAULT'... ok Test 'Test_004_GenerationOfELOOP'... ok Test 'Test_005_GenerationOfENOTDIR'... stat(dir1/file2/object, ...) got error 2 (No such file or directory) while we would have expected error 20 (Not a directory) *** ExpectCall_Stat FAILED at line 203 ! *** Test 'Test_005_GenerationOfENOTDIR' FAILED ! Test 'Test_006_GenerationOfENOENT'... ok Test 'Test_007_GenerationOfENAMETOOLONG'... ok Test 'Test_001_BasicSymLink'... ok Test 'Test_003_GenerationOfEEXIST'... ok Test 'Test_004_GenerationOfEFAULT'... ok Test 'Test_005_GenerationOfENOENT'... *** Check_DirEmpty FAILED at line 160 ! *** Test 'Test_005_GenerationOfENOENT' FAILED ! Test 'Test_006_GenerationOfENOTDIR'... symlink(non_existing_object, dir1/file2/symlink) got error 2 (No such file or directory) while we would have expected error 20 (Not a directory) *** ExpectCall_SymLink FAILED at line 182 ! *** Test 'Test_006_GenerationOfENOTDIR' FAILED ! Test 'Test_007_GenerationOfENAMETOOLONG'... ok Test 'Test_001_BasicUTime'... File file has modification date 2405181940.0 (0x8f5c29f4 0x) 'Sat Feb 12 11:37:24 1910', but we expected 4294967295.0 (0x 0x) 'Wed Dec 31 23:59:59 1969'. *** Check_FileModDate FAILED at line 55 ! *** Test 'Test_001_BasicUTime' FAILED !
[gccsdk] [Bug 249] GCC 4.7.4 Rel 1 Dev 2014-01-08: mktime() returns wrong value
http://www.riscos.info/bugzilla3/show_bug.cgi?id=249 John Tytgat john.tyt...@aaug.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from John Tytgat john.tyt...@aaug.net 2014-03-08 17:31:43 PST --- The RISC OS to Unix time conversion did use more than 5 bytes of input data. Should be solved with r6621. -- Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] fgets problem/Unixlib
In message 20140308201749.gy6...@chiark.greenend.org.uk Theo Markettos t...@markettos.org.uk wrote: On Sat, Mar 08, 2014 at 04:34:37PM +0100, John Tytgat wrote: Roughly a year ago I did several UnixLib fixes for returning more accurate errno error values and made a small unittest framework (recipe/files/gcc/libunixlib/unittest) for testing these changes. It would be interesting to have those unittests run on HostFS instead of a FileCore based FS what I used at that time. My guess is that HostFS will fail more of those unittests... Here you go. RPCEmu 0.8.9, RISC OS 5.20 (10 Jun 2013), Mac OS 10.9. It does fail a few... Yes, but I forgot to mention that on a FileCore FS not all tests pass either. [...] [rename unittest] Test 'Test_001_BasicRenameFile'... ok Test 'Test_002_BasicRenameDir'... ok Test 'Test_003_BasicRenameSymLink'... ok Test 'Test_004_RenameFileAndDstExists'... ok Test 'Test_005_RenameDirAndDstExists'... ok Test 'Test_006_GenerationOfEISDIR'... ok Test 'Test_007_GenerationOfENOENT'... rename(file, dir/nodir/foo) got error 0 (Success) while we would have expected error 2 (No such file or directory) *** ExpectCall_Rename FAILED at line 243 ! *** Test 'Test_007_GenerationOfENOENT' FAILED ! This is a suspicious failure. Test 'Test_008_GenerationOfENOTDIR'... rename(file/nofile, other_file) got error 2 (No such file or directory) while we would have expected error 20 (Not a directory) *** ExpectCall_Rename FAILED at line 282 ! *** Test 'Test_008_GenerationOfENOTDIR' FAILED ! Test 'Test_009_GenerationOfEFAULT'... ok Test 'Test_010_GenerationOfEINVAL'... rename(dir, dir/subdir/foo) got error 88 (Bad rename) while we would have expected error 22 (Invalid argument) *** ExpectCall_Rename FAILED at line 340 ! *** Test 'Test_010_GenerationOfEINVAL' FAILED ! This one as well. [...] [utime unittest] Test 'Test_001_BasicUTime'... File file has modification date 2405181940.0 (0x8f5c29f4 0x) 'Sat Feb 12 11:37:24 1910', but we expected 4294967295.0 (0x 0x) 'Wed Dec 31 23:59:59 1969'. *** Check_FileModDate FAILED at line 55 ! *** Test 'Test_001_BasicUTime' FAILED ! Bizar failure. Test 'Test_002_GenerationOfENOENT'... utime(file, 0xa6fac) got error 0 (Success) while we would have expected error 2 (No such file or directory) *** ExpectCall_UTime FAILED at line 106 ! *** Test 'Test_002_GenerationOfENOENT' FAILED ! Likewise. Test 'Test_003_GenerationOfEFAULT'... ok Test 'Test_004_GenerationOfENAMETOOLONG'... ok [utimes unittest] Test 'Test_001_BasicUTimes'... File file has modification date 0.0 (0x 0x) 'Thu Jan 01 00:00:00 1970', but we expected 0.02000 (0x 0x01312d00) 'Thu Jan 01 00:00:00 1970'. *** Check_FileModDate FAILED at line 57 ! *** Test 'Test_001_BasicUTimes' FAILED ! No centi-second modification date precision... Test 'Test_002_GenerationOfENOENT'... utimes(file, 0xa6fa4) got error 0 (Success) while we would have expected error 2 (No such file or directory) *** ExpectCall_UTimes FAILED at line 115 ! *** Test 'Test_002_GenerationOfENOENT' FAILED ! Bizar failure. Test 'Test_003_GenerationOfEFAULT'... ok Test 'Test_004_GenerationOfENAMETOOLONG'... ok On the other hand, non of these tests show the open()/EOPSYS issue you've reported. John. -- John Tytgat, in his comfy chair at home john.tyt...@aaug.net ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
