[00:16:38] --- Russ has left: Disconnected [06:43:18] --- jaltman has left: Disconnected [08:04:20] --- jaltman has become available [08:08:08] --- jaltman has left: Replaced by new connection [08:08:09] --- jaltman has become available [08:47:38] --- sxw has left [10:00:03] --- jaltman has left: Disconnected [10:01:37] --- Russ has become available [10:05:18] hm. afsdb with dynroot needs a blacklist [10:34:35] --- Simon Wilkinson has left [11:14:13] --- dev-zero@jabber.org has left: Replaced by new connection [11:14:15] --- dev-zero@jabber.org has become available [11:54:59] --- deason has become available [14:27:55] --- Simon Wilkinson has become available [15:20:47] --- Jeffrey Altman has become available [17:58:10] --- jaltman has become available [18:08:08] hm, so, the size_t printf thing appears to be slightly harder than even what we were discussing before [18:08:47] we can't use __STDC_VERSION__ to detect if %zu is available, since gcc by default is only in c89-plus-gnu-stuff, so we wouldn't get %zu for the case where we specifically want it [18:09:46] would using %zu just for gcc and %lu everywhere else be acceptable? I don't see any way to detect if %zu specifically is available short of running a configure test that actually runs a program trying to use it [18:15:28] To get the correct value on Windows, %Iu is used. That will be 64-bit on 64-bit systems, and 32-bit on 32-bit systems. [18:18:00] yes, I assumed the windows case was correct; sorry, "everywhere else but still *nix" [18:18:51] (and %lu on *nix as in "ell-you", %Iu on windows as in "eye-you") [18:27:32] You need an Autoconf macro to check whether %zu is available. [18:28:22] yes, I would like that; is there any way short of a runtime test to detect it? [18:28:33] I don't think so. :/ Which sucks. [18:28:44] Oh, wait, no, there is. [18:28:47] Right, right. [18:28:53] You don't use %zu at all. [18:28:58] You use the C99 symbol. [18:29:06] And if it's not defined, you assume you don't have %zu. [18:29:22] I remember the discussions about this on other lists now. [18:29:34] I'm also not sure a runtime test would even be accurate, I mean libc on the running host may not support it when the libc on the build host could [18:30:06] what symbol? the only one I saw when searching was PRIuSIZE, which doesn't actually exist, but was proposed [18:33:47] Ah, I see the problem; none of that exists for size_t. [18:33:55] A runtime test would be fine. [18:34:01] But it sucks for cross-compiling. [18:35:04] if you use %lu sometimes when we could have used %zu isn't the end of the world; we've always been using %lu up until now anyway [18:35:15] I suspect we need to use a runtime test and fall back on %lu. [18:35:21] If we can't run the runtime test. [18:37:18] yes, but I'd be more worried if somehow we get a build host that supports %zu, and a machine that doesn't support %lu runs the binaries from that machine [18:37:24] or does that just not happen? [18:38:23] That just does not happen. That would require a massive screwup by the libc maintainers. [18:39:00] Adding support for %z is a change in the semantics of printf that require versioning the symbol. Binaries built against that libc won't run with older libcs. [18:42:43] runtime switch for %z: why? i mean, i get why you'd want %z but why is it worth it [18:43:34] i guess the right way to phrase it: is %z worth it? [18:43:52] well, to squash the relevant warnings we either need to turn on %z, or cast everything [18:44:49] if we have no portable way to make those warnings go away, perhaps maybe those warnings can't go away. this makes me sad but it doesn't make me want to do things which involve new risks [18:45:31] warnings are ok if you understand the risk they're screaming about. does %z carry enough less risk? [18:45:36] (i don't know) [18:45:55] if we ignore -Wformat, we can miss a lot of potential errors [18:46:16] i didn't suggest ignoring it globally. [18:46:19] By runtime test, we mean something in Autoconf that runs a program. [18:46:28] Not runtime in the sense of at the time the binary starts. [18:46:45] there is no finer granularity than once-per-file that I'm aware of, with gcc [18:46:47] sure. are we going to link to libc static? [18:46:51] The drawback is that generally you don't want to try to run programs in configure, since it breaks horribly in cross-compiling. [18:47:01] there's plenty finer grain: i have grep [18:47:01] You don't have to link libc static. [18:47:16] If configure builds a program with printf %z that works, it will work on every host that can run those binaries. [18:47:35] only if i trust the libc versioning [18:47:44] if you're not convinced that's safe, we could just turn on %z for gcc or something [18:47:47] (or gcc >= 4) [18:47:48] (or know that systems whose libc versioning sucks don't matter) [18:47:50] I'll be shocked if you can't trust it for that. [18:47:54] Because of that. [18:48:05] because of (which) that? [18:48:07] The systems where it sucks don't matter because they don't support %z anyway because they haven't had a new release in five years. [18:48:20] that's a reasonable argument [18:48:42] --- abo has left [18:48:42] but could they in the future? (no idea what they are, so I have no idea) [18:48:43] deason: support for %z doesn't have anything to do with what compiler you use, unfortunately. [18:49:01] --- haba has left [18:49:03] --- abo has become available [18:49:15] well, gcc has a builtin for it [18:49:19] Basically, %z is going to work everywhere except for IRIX, old HP-UX, etc. [18:49:20] --- haba has become available [18:49:29] gcc only has a built-in for printf with static arguments. [18:49:35] bah [18:49:36] It doesn't generically replace printf. [18:49:50] The built-in is only there to translate printf into puts when possible. [18:49:53] gcc is a special case, and i hate __eprintf, btw [18:50:43] also, in general, we don't build on a new system and then try to run the binaries on an old system, at least not for new/old of the level that would involve features like %z going away. [18:51:02] Building Solaris binaries on Solaris 10 and then trying to run them on Solaris 9, that sort of thing, generally isn't going to work anyway. [18:51:04] we do for irix, but... [18:51:19] apparently the irix build machine i have is like, ancient [18:51:22] But that's just because IRIX isn't having real feature releases, yes? [18:51:35] I mean, they're not doing things like adding C99 support to libc to IRIX any more, are they? [18:51:40] 6.5.22m or something has enough changes that inode fileserver apparently isn't safe anyway [18:51:45] /anyway/anymore [18:52:01] I can believe that, but the inode fileserver is way more fragile than fundamental libc features like printf. [18:52:10] sure. [18:52:46] Alternately, we could just leave it alone for another five years and then use %z everywhere unconditionally and not care. [18:53:03] We're still at the tail end of the annoying portability period. [18:53:28] Or we could just always use %lu and a cast. Which to be honest is what I do with all my other code since I never felt like dealing. [18:53:50] The code to use %z conditionally is going to be ugly. [18:53:56] Since we need to conditionally add a cast as well. [18:54:08] the cast method scares me less but if i had trailing edge systems to play with for aix and hpux i suspect i might be less worried [18:54:26] Unless we can assume that size_t == unsigned long (not just <=) on every platform without %z. [18:54:43] Which I suppose maybe we can. [18:54:45] I guess. [18:54:55] * Russ suspects that %lu and a cast to unsigned long is the easiest thing to do. [18:55:35] HPUX I know at least supports %Z. I dunno if they also support %z. [18:55:35] --- haba has left [18:55:37] --- deason has left [18:55:53] --- haba has become available [18:56:18] --- deason has become available [18:56:20] there are two issues with casting. (a) is the actual size of size_t larger than the size of a long? (b) are any of the values that we actually use size_t for greater than can be represented by a long? [18:56:31] --- deason has left [18:56:40] size_t is never larger than unsigned long on any UNIX varient. [18:56:49] --- deason has become available [18:57:03] that may be but it isn't a requirement [18:57:18] I thought it was for.... something; c89? [18:57:23] Yes, but it's not a requirement in much the same way that it's not a requirement that all-bits zero be a NULL pointer. [18:57:36] It's not a requirement, but if you break it, you're in WEIRD exotic shit, and lots and lots of stuff will break. [18:57:54] except that we know of systems (non-unix) where sizeof(size_t) > sizeof(long) [18:58:00] All GNU code assumes that size_t is never larger than unsigned long. It's in the GNU coding standards. [18:58:04] Yes. But not UNIX. [18:58:08] maybe that's what I'm thinking of [18:58:09] I guarantee it. [18:58:20] then just use the cast [18:58:39] if that's a concern, why not just cast to a 64-bit size_t? [18:58:43] just don't apply a cast in such a manner to apply a cast on Windows [18:59:08] Windows can have size_t > long, right? [18:59:25] On Windows, size_t tracks the size of a pointer [18:59:34] and long is always 4 [18:59:54] Yeah. [18:59:58] it will be interesting to see what happens for Win8 which will be a 128-bit OS [18:59:59] So we have to wrap the cast anyway. [19:00:15] If we have to wrap the cast anyway, supporting %z if we detect it is actually pretty easy. [19:00:18] The code is just as ugly any way. [19:00:47] ugh, but having both a format string macro and a cast abstraction is ugh [19:01:07] Yeah. [19:01:33] --- abo has left [19:01:45] in general I try to avoid using size_t because it is not a fixed size [19:02:04] --- abo has become available [19:02:08] --- haba has left [19:02:36] --- haba has become available [19:02:37] is using %llu and casting unsafe? that would only require a cast and not the fmt macro [19:03:07] %llu is not supported on Windows. [19:03:30] right; we have AFS_UINT64_FMT [19:03:31] use %I64u if you want a 64-bit value to be represented [19:03:33] so we need one anyway [19:04:20] jaltman: Can you use %lu for size_t on Windows if a long is always 32 bits? [19:04:33] I'm confused by the combination of things you said above. [19:04:50] deason: Not all platforms have a "long long" type. [19:04:56] We get back into problems with IRIX, AIX, etc. [19:05:23] oh, that abstraction for 64-bit ints isn't just old obsolete cruft? [19:05:25] size_t is not always 32-bits [19:05:29] deason: Right. [19:05:43] jaltman: Right, but way back above you said that you were using %lu on Windows for size_t. [19:05:46] So I'm confused. [19:05:48] Oh. [19:05:51] This is that font thing again. [19:05:52] Sigh. [19:05:56] capital i. [19:06:00] Not l [19:06:00] %Iu not %lu [19:06:09] * Russ needs a better font. [19:06:35] So we need both the format thing and the cast thing. [19:06:38] To fix this. [19:06:43] So we may as well support %z. [19:06:51] well wait, wait [19:07:05] jaltman: Is Microsoft going to support %z? [19:07:18] maybe I just forgot something, but why do we need a cast for the *nix case when we don't have %z? [19:07:38] does anything really have a sizeof(size_t) < sizeof(long)? [19:08:30] Yeah, we probably don't need a cast on UNIX if we don't have %z. We'd be assuming that size_t == unsigned long, but that's probably okay to assume. [19:08:47] russ: I can't say what Microsoft may or may not support in the future. the tools we build with to support Win2000 do not support it [19:08:50] the warnings we've gotten from it so far have been "got a unsigned int, expected unsigned long" even when the sizes are the same [19:09:13] * Russ is hoping that eventually we can just use %z everywhere. [19:09:21] Well, if the warning is right, that's a serious problem. [19:09:32] But if you used %lu, the warning is bogus. [19:09:48] err, sorry, yeah, other way around [19:10:04] --- abo has left [19:10:12] but I meant when fiddling around with the strings, you try %lu, you get warnings on some platforms, you try %u, you get warnings on others [19:10:15] GCC is going to always warn about printf of size_t with anything other than %z without a cast. [19:10:19] even though the sizeof's are the same [19:10:30] GCC doesn't care about the underlying size, just about the type. [19:10:48] so, a cast in the non-%z case would just be silencing a warning, and if we don't have %z, I am assuming --enable-checking won't even work there anyway [19:10:49] At least with modern GCC. [19:10:52] --- abo has become available [19:10:53] Older GCCs do various broken things. [19:11:09] yeah. So I think we can assume size_t == unsigned long if we don't have %z. [19:11:19] --- asedeno has left [19:11:24] --- asedeno has become available [19:12:14] Now jhutz is going to read this whole discussion and come up with some fantastic example of something I forgot. [19:16:16] better now than later [19:44:36] --- Jeffrey Altman has left: Replaced by new connection [19:45:03] --- jaltman has left: Replaced by new connection [19:45:04] --- jaltman has become available [22:02:15] --- deason has left [22:27:19] --- reuteras has become available [23:27:12] Until this is resolved, can we back out the size_t patch? [23:31:42] Oh, and the other option is not to bother with casting, but to say that --enable-checking will only work either on platforms which have %zu, or where size_t is printable with %lu. I think that should cover most of our bases. [23:40:22] --- dev-zero@jabber.org has left