[09:43:15] --- deason/gmail has become available
[09:44:06] <kaduk@mit.edu/barnowl> deason: do you have any insight into the solaris build failure for
9975?
[09:48:34] <deason/gmail> I assume you're wondering why PATH_MAX seems to get transformed to MAX_PATH ?
[09:49:01] <kaduk@mit.edu/barnowl> Well, knowing where that happens would be helpful.
It would be more helpful to have a useful workaround, though.
[09:51:55] <deason/gmail> I don't see where that could be happening in the system headers, but also don't see where it could be in openafs
[09:52:12] <deason/gmail> I'm pretty sure there's a ticket about this, by the by
[09:52:26] <kaduk@mit.edu/barnowl> The symbol renaming, or the realpath buffer size?
[09:52:28] <deason/gmail> I mean, not the MAX_PATH thing I was just talking about, but the realpath thing
[09:53:37] <kaduk@mit.edu/barnowl> Okay, I will look.
[09:54:44] <jaltman/FrogsLeap> https://rt.central.org/rt/Ticket/Display.html?id=130719
[09:56:25] <kaduk@mit.edu/barnowl> (I ran into it in butc, not in bosserver, but figured we might as well
fix both instances of realpath.)
[09:56:56] <kaduk@mit.edu/barnowl> Do we think that 4096-byte buffers are too big for stack allocation?
[10:08:01] <jaltman/FrogsLeap> I wouldn't risk a 4K allocation on the stack
[10:23:29] <kaduk@mit.edu/barnowl> Ah, right, roken-common.h has a #define PATH_MAX MAX_PATH
[10:24:08] <kaduk@mit.edu/barnowl> (if PATH_MAX is not defined), but it doesn't check whether MAX_PATH is
defined.
[10:27:29] <kaduk@mit.edu/barnowl> Anyone here feel like patching heimdal, or should I send a pull
request?
[10:34:12] <kaduk@mit.edu/barnowl> Hmm, or does userok not have limits.h?
[10:36:59] <kaduk@mit.edu/barnowl> Maybe I will ask buildbot to check that.
[10:37:20] <kaduk@mit.edu/barnowl> Unless there is a decent way to untangle the include chain for an OS
that I'm not runnin?
[10:42:49] <jaltman/FrogsLeap> send a pull request
[12:15:17] --- deason/gmail has left
[15:44:51] --- jaltman/FrogsLeap has left: Disconnected
[15:48:20] --- jaltman/FrogsLeap has become available
[15:49:43] <jaltman/FrogsLeap> pullup performed
[15:50:05] <andersk> A 4 KiB stack allocation is a terrible idea in kernel space (that’s the entire size of a Linux kernel stack), but it ought to be totally fine in userspace (where stacks are typically more like 8 _MiB_).
[15:50:33] <jaltman/FrogsLeap> not on my platform 
[15:53:34] <andersk> Windows?  You still get a 1 MiB default there, right?
[15:56:57] <jaltman/FrogsLeap> its complicated.   The default size set in the process header by Microsoft Linker is 1MiB but the actual size allocated is dependent upon a number of factors
[15:57:57] <jaltman/FrogsLeap> The 1MiB default is for X86 and X64.  Itanium was 4MiB and I'm not sure what ARM is
[16:11:40] --- mvitale has become available
[16:21:48] <andersk> Point being that either way, you’re not going to miss a couple of stack KiB in a nonrecursive function.  That kind of thinking is what lands you with code full of static buffers and reentrancy bugs.
[17:15:51] --- mvitale has left
[17:43:32] --- mvitale has become available
[17:44:22] <jaltman/FrogsLeap> andersk: avoiding large stack allocations is performed by using the heap not statics and not globals.  
[19:07:04] --- mvitale has left
[20:52:30] <kaduk@mit.edu/barnowl> > pullup performed
Er, that just means that Love took it into heimdal, right?
I don't see anything in OpenAFS-land.
[20:54:04] <jaltman/FrogsLeap> if you want it in OpenAFS you need to import the change
[20:57:57] <jaltman/FrogsLeap> use the src/external/import-external-git.pl script
[21:06:01] <kaduk@mit.edu/barnowl> I found that script, but had to disappear to do other things.
[21:06:45] <kaduk@mit.edu/barnowl> Probably we should just make sure that limits.h gets included, though.
Do you have a sense for whether that is an unportable header given the
platforms we support?