> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf > Of Christian Böhme > Sent: Tuesday, July 31, 2018 10:16 > > On 30.07.2018 20:12, Michael Wojcik wrote: > > > FWIW, SUS Issue 5 defines RLIMIT_AS as applying to both malloc and mmap, but RLIMIT_DATA as > > applying only to malloc. (That is, mmap'd pages do not count against the data limit.) > > mmap() , by defninition, populates the process' virtual address space, and if that > is limited in size, artificially or not, then the call is going to fail, eventually. That's irrelevant to the statement you quoted, which was about the SUS process-limit mechanism (setrusage et al.), not the process address space. > > Agreed. And I'm not endorsing the mmap approach for this problem anyway - I'd use a streaming > > approach, so I'm not limited by address space. > > This structure, if held in a regular file, can be processed quite non-linearly, > and without mmap()'ing its entire contents. Indeed. I still don't see any compelling reason to mmap it at all. > The pure streaming approach may be appropriate for file descriptors that are not > seekable like sockets, pipes, tty ends etcpp., whereas with egular files, random > access schemes using either pread(v)(2) or lseek(2) in combination with > read(v)(2) can be employed. Or regular files could also be processed sequentially. What's the advantage of making seekable sources a special case? In any case, the OpenSSL apps are a convenience and a set of samples. You can always write your own version of the cms app. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
