6 ms·
Going long long on time_t
- throwaway_yy2Di 13y agoIf anyone has trouble reading this, there's also plain text versions of individual slides: http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp00002.txt http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp0000... http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp00003.txt http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp0000... etc. Here's the whole thing in one page, minus images: https://gist.github.com/anonymous/6757266/raw/3469464cb802e7c9a6cbe7c2508b252f7ad8ebdd/Theo+de+Raadt%3A+Going+long+long+on+time_t+to+cope+with+2%2C147%2C483%2C647%2B1 https://gist.github.com/anonymous/6757266/raw/3469464cb802e7...
- simias 13y agoMy god, I'm not a fan of reading slides in general but this... this is a new dimension of horror. I can't shake the feeling that there's some sick humour in this.
- tiziano88 13y agoComic saaaaaaaaans!
- parennoob 13y agoWhat'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 actually presented his talk like this, that's extra bad).
- michaelhoffman 13y agoIt might not be immediately obvious that you can zoom in on a slide by clicking on it.
- p1mrx 13y ago> What's so horrible about it? It's Comic Sans with JPEG artifacts. The only consolation is that it doesn't blink.
- claudius 13y agoIt might have been difficult to combine blinking GIFs with JPEG artefacts – that said, it wasn't all that bad with the mouse on the ‘next’ link and tapping of the left mouse button to read the next slide, at least it works in Opera :)
- spongle 13y agoThe content was good though which after all is the main thing...
- eddieh 13y agoTrue, but the font detracts from the technical content. Presentation of information is important. There are cognitive and psychologic implications that your reader will incur when reading a document written in Comic Sans. There is nothing to be gained from using Comic Sans and it's not difficult to simply not use the font.
- mistercow 13y agoNot 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.
- ciupicri 13y agoIt'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/ http://threebean.org/presentations/fedmsg-flock13/ [2]: http://hovercraft.readthedocs.org/ http://hovercraft.readthedocs.org/ [3]: https://github.com/adamzap/landslide https://github.com/adamzap/landslide
- rwmj 13y agoOr just use HTML (rendered with Webkit): http://rwmj.wordpress.com/2012/01/31/tech-talk-pse-1-1-0/#content http://rwmj.wordpress.com/2012/01/31/tech-talk-pse-1-1-0/#co... and embed terminals and other programs along the way.
- durin42 13y agoI've been using dzslides (https://github.com/paulrouget/dzslides https://github.com/paulrouget/dzslides) and been pretty happy. I wrote my own tool to take markdown and emit dzslides and I've not been upset yet, but my slides tend to be very minimalistic.
- deleted 13y ago[deleted]
- jensenbox 13y agoNo humor at all, it is real and frankly, I am worried for my children. http://y2038.com/ http://y2038.com/
- enneff 13y agoWTF. I'm not sure I want to live in a world where plain text should elicit such a reaction!
- alextingle 13y agoAny idea why they would use long long rather than int64_t?
- sirclueless 13y agoint64_t is a userspace libc typedef. long long is ICO C (C99) and guaranteed to be 64 bits or more.
- alextingle 13y agoSo stdint.h not available to kernel programmers. Thanks.
- pslam 13y agoI always found this special-casing of headers for kernel vs user unnecessary and complicating. In the many embedded runtimes I maintain, I've moved towards using standard POSIX-y and C(++) standard headers everywhere. I know kernel folks love to believe that their world is special so all the usual C library stuff needs to be done differently, but it's not needed. It's so much easier to port code between the two worlds when you don't have to litter the #include prelude of every C file with conditionals.
- _kst_ 13y agostdint.h may not be available, but int64_t is; it's defined in include/linux/types.h.
- alayne 13y agoThe OpenBSD kernel probably doesn't use Linux headers.
- asveikau 13y agoA few times I got flamed on this site for complaining that the average HNer can't have reasonable discussions about C. I think the comment that the OpenBSD team should just #include <linux/types.h> pretty well shows that I was right. :-)
- cbsmith 13y agoSo, this slide confused/troubled me: http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp00029.html http://www.openbsd.org/papers/eurobsdcon_2013_time_t/mgp0002... I don't see why it would be a good idea to convert "time_t" to "long long". Having an alias specifically for time_t is part of what makes this kind of work doable. I could see maybe introducing another alias like "time64_t" or something, but once you convert it to "long long" the type is no longer tagged in a way that makes it easy to find and more importantly suggests to the programmer they ought to NOT make assumptions about its size. Heck, in a perfect world I'd either introduce a new % symbol specifically for time_t width or have a macro that expands to represent its width (not to mention make it mandatory to use compiler warnings about string formats not matching argument widths). I also found the comment about "would love better compiler tools -- none found so far". Certainly there are things like Sparse (https://sparse.wiki.kernel.org/index.php/Main_Page https://sparse.wiki.kernel.org/index.php/Main_Page) which correctness verification easier.
- dmm 13y agoThe typedef 'time_t' is definitely being used, for example is is a patch from sys/kern/kern_clock.c: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_clock.c.diff?r1=1.81;r2=1.82 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_cloc... That was part of a larger changeset that enabled 64bit time_t on 2013-08-13. The 'long' type is changed to 'time_t', which is now 64bit everywhere on OpenBSD. I didn't see think talk but I think it's confusing because we are just seeing the slides. Here is what I got from it: remove time_t from network/on-disk/database formats Right now if you have a userspace app that has some kind of binary disk format, say a database, and you use the time_t typedef your binary files will not be portable between systems which have differently sized time_t's. However, if you use 'long long' or 'int64_t' and cast time_t's to those, your files will be portable and 64bit everywhere. If you're using time_t in network formats, systems with different time_t sizes will confuse each other! remove as many (time_t) casts as possible This is trouble because you don't know the size of time_t, if it's 32bit you might be truncating! It's better to cast to a 64bit size, that will always work, at least for the next 292 billion years.
- 13y ago
- Peaker 13y agoFor format strings, why not do the inttypes.h thing, and define a macro for the format specifier of (time_t)? "%" PRI_TIME_T
- tedunangst 13y agoOpenbsd does not believe in the use of the format string macros.
- aidenn0 13y agoAny idea of the motivation behind that?
- tedunangst 13y agoIt's ugly.
- deleted 13y ago[deleted]
- Peaker 13y agoIt's superficially ugly. It's deeply ugly to have to maintain "%llu", "%lu", and various other format strings for a single (uint64_t) or indeed (time_t). It's also ugly to up-cast everything to the largest potential size whenever you use format strings. This seems like a case of choosing deep ugliness over superficial ugliness... "%" PRIu64 ": The time is: %" PRI_TIME_T, x, y Seems nicer to me than: "%llu: The time is: %lld", (long long unsigned)x, (long long)y /* time_t is signed? Who knows? */ What type would you use if you wanted to print uint128_t? %llld ? Finally, I think rejecting a standard C header file because it is "ugly" and coming up with your own solution is unnecessarily fragmenting things, especially when it isn't clearly better (IMO it is clearly worse).
- asveikau 13y ago> rejecting a standard C header file because it is "ugly" I just checked an OpenBSD machine's inttypes.h. Some of the format macros (I presume the ones present in the standard) are there. So I can't say they rejected the header. It would probably be weird to introduce one there that isn't in the standard. OTOH %lld for long long is in the standard.
- pjbringer 13y agoI notice the ideas that it is not the number of contributors that matter, but the number of sufficiently skilled ones, and the that popularity impedes change. I can't help draw a parallel with the advice that you should listen to your most valuable customers, and potential customers, and that the rest of your users will expect free stuff, and complain loudly when you pivot.
- snoonan 13y agoIt's going to be a long long time_t. (sorry.)
- liveoneggs 13y agoNetBSD did this a while ago, but was better about binary compatibility and things. http://www.netbsd.org/changes/changes-6.0.html#time_t http://www.netbsd.org/changes/changes-6.0.html#time_t
- gizzlon 13y agoGood read, even if you, like me, don't care too much about the low-level stuff.. A few takeaways: - Embedded 32bit is everywhere. Sure they'll fix the obvious ones, but I'm sure some things will be forgotten about. This problem might not be taken seriously after the Y2K debacle. - The OpenBSD guys & gals like to do implement new designs and ideas. Sometimes radical. (but I already knew that) - A transitional solution can end up being the solution ans stick around forever :( - Theorem "In operating systems, increased popularity leads to greater resistance to change". Probably true in most "products".
- JoachimS 13y agoYes, and that some embedded 32-bit systems deployed today will be in service come 2038. And quite probably some 16-bit, 8-bit ones too.
- thaumaturgy 13y ago> This problem might not be taken seriously after the Y2K debacle. I wish people would stop saying things like that. I was one of many programmers who spent some overtime over the course of about a year on fixing code in 1998-9. I was just the junior programmer at the time; the head guy in the department had some nearly sleepless nights around then. I can promise you that in one East Bay school district, nobody would've gotten their paychecks, report cards would not have worked, DNS would have stopped working for the entire school network, and finance & budget would have had some really crazy errors in the output -- those are the systems I still remember requiring the most attention. Y2K was a "debacle" because a bunch of people busted their asses fixing old code. It feels a lot like pulling two consecutive all-nighters as an engineer on a project, to bring the project up to its deadline on-time and under-budget, only to have your department manager the next morning stroll in, well-rested, coffee cup in hand, and say, "See? Told you it was no big deal."
- deleted 13y ago[deleted]
- gizzlon 13y agoFair enough, it's not the most fitting term. I remember a lot of hype and no actual problems. I suspect others do as well, and this could lead to people thinking about the whole problem as over-hyped and a non-issue. Not saying that it's correct, but that's the catch-22 of preventing problems: If you do a too good job, nobody will notice =/
- dllthomas 13y ago... and I think it's gonna be a long long time.
- meshko 13y agoFunny they don't mention that starting Visual Studio 2005 time_t is 64bit on 32bit builds.
- tedunangst 13y agoHow did they resolve compatibility issues with existing code?
- meshko 13y agoI assume the same exact way that the presentation describes? Plus they added a macro you can define to go back to 32bit time_t (which is probably what most app devs did...)
- eliteraspberrie 13y agoThe C standard only states that time_t is an integer (or floating-point) type, and POSIX further states it represents seconds since the epoch, so a 64-bit time_t is a good solution. In 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 <sys/types.h> @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 <sys/types.h> @stdio@ @@ #include <stdio.h> @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. [1] http://coccinelle.lip6.fr/ http://coccinelle.lip6.fr/