Earlier quoted context omitted.
Not having any way to navigate without actually clicking the tiny "next" link is infuriating. I can't actually focus on the subject matter if I have to do that.
> the tiny "next" link Once you zeroed in on the link, it's not like you have to move the mouse away, and its Fitt size becomes essentially infinite past the first slide.
Going long long on time_t
71–80 of 92 posts
Re: Going long long on time_t
#72Re: Going long long on time_t
#73Earlier quoted context omitted.
I agree, and consider that one of the inherent problems with the string formatter approach to IO. That said, time is perhaps one of the data types that is universal enough and general enough to the C runtime that you could make a case for it.
I've always felt that the 'right' solution was to emulate glibc and provide facilities for registering new format specifiers[1]. Then libraries could provide specifiers for everything that made sense and users could pick and choose. Of course, there would be performance implications - not to mention the added complexity for implementors. [1] http://www.gnu.org/software/libc/manual/html_node/Customizin...
Re: Going long long on time_t
#74Earlier quoted context omitted.
once again, how do the headers conjure up the int64_t type? it's not a keyword.
Here is how stdint.h on Linux conjures up the int64_t type. #if __WORDSIZE == 64 typedef long int int64_t; #else typedef long long int int64_t; #endif
Re: Going long long on time_t
#75Funny they don't mention that starting Visual Studio 2005 time_t is 64bit on 32bit builds.
Re: Going long long on time_t
#76Earlier quoted context omitted.
I fail to see why it's more reasonable to prefer "long long" to "int64_t" just because the former existed for longer. It's not year 2000 today and C99's not a hot new thing not many compilers support. Or OpenBSD do have some policy that their kernel must be able to build with any C89-compliant compiler?
Microsoft's C compiler doesn't have C99 support.
Re: Going long long on time_t
#77Funny they don't mention that starting Visual Studio 2005 time_t is 64bit on 32bit builds.
How did they resolve compatibility issues with existing code?
Re: Going long long on time_t
#78Earlier quoted context omitted.
What's so horrible about it? Obviously, it isn't on the same level as any of the slide decks web designers put up that are in a sane format (HTML5+js / PDF) which don't require you to actually click through, but then a) Theo De Raadt works much further down the stack b) This is probably something put up by the EuroBSDCon folks after converting his slides (can someone who was at the Con weigh in on this? If he actuall…
It's 2013 and there are tons of programs that can generate a decent HTML based presentation from a text file. Heck, I've encountered one just today while looking at the slides for "fedmsg - The Fedora Infrastructure Message Bus" [1]; the tool is named hovercraft [2]. Another nice tool is landslide [3]. [1]: http://threebean.org/presentations/fedmsg-flock13/ [2]: http://hovercraft.readthedocs.org/ [3]: https://github.…
Re: Going long long on time_t
#79In order to find and change occurrences of time_t in ports more easily, they could use the Coccinelle tool.[1] The following semantic patch would find and replace variable declarations of type time_t:
@sys_types@
@@
#include
@time_t depends on sys_types@
identifier x;
@@
- time_t x
+ long long int x
;
Replacing printf format specifiers is more difficult, so the following semantic patch will find printf statements which use time_t variables, which can then be edited manually: @sys_types@
@@
#include
@stdio@
@@
#include
@printf depends on sys_types && stdio@
identifier x;
@@
time_t x;
...
* printf(..., x, ...);
These can be used as follows: $ spatch --sp-file foo.cocci --dir /path/to/ports
where `foo.cocci` is the name of one of the semantic patches above.Re: Going long long on time_t
#80Earlier quoted context omitted.
Is there anything that forbids those utilities from using system-provided headers and time_t? I think they'll build fine on any POSIX.1-compliant system then. Unless they're doing something really weird with time_t values, I don't think there's any reason they should know whenever it's long long or int64_t or whatever under the hood.
printf("%lld", (int64_t) t); wouldn't build on a system that doesn't have int64_t, so one needs to use long long.
And I thought `%lld` actually means `long long`... So, http://ideone.com/SJJFPs seems like a proper approach to me. That said, if compiler supports %lld (an %I64d or alike might be required for older compilers), so a better cross-compiler approach would be in lines of `printf("test: " TIME_FMT "\n", (TIME_FMT_CAST)t)`. Or, ahem, maybe, `print_time(t)`.