hnsl / librcd Goto Github PK
View Code? Open in Web Editor NEWA library for Rapid {C|Concurrency|Correct} Development
License: Other
A library for Rapid {C|Concurrency|Correct} Development
License: Other
https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2014-02
#0: 0x549643 gcm_auth_decrypt in gcm.c:317
#1: 0x4ceeff ? in stack.s:85
#2: 0x53f5e0 ssl_decrypt_buf in ssl_tls.c:1275
#3: 0x4ceeff ? in stack.s:85
#4: 0x53f09f ssl_read_record in ssl_tls.c:2006
#5: 0x4ceeff ? in stack.s:85
#6: 0x5425c7 ssl_read in ssl_tls.c:3703
#7: 0x52dcc2 __librcd_ifc_join__tls_read in polar.c:118
#8: 0x4ceeff ? in stack.s:85
#9: 0x52dc32 tls_read in polar.c:112
#10: 0x52f45a tls_rio_read in polar.c:323
#11: 0x4ceeff ? in stack.s:85
#12: 0x4d8f15 rio_read_direct in ?:?
#13: 0x4d9753 rio_peek in rio.c:1403
#14: 0x490b7c http_session in wsr.c:360
#15: 0x4ceeff ? in stack.s:85
#16: 0x48ef22 _http_connection_fiber in wsr.c:821
#17: 0x4ceeff ? in stack.s:85
Currently librcd depends on a mix of (L)GPLv2 and GPLv3-licensed libraries, making distribution of binaries impossible. We need to replace those by either newly written code distributed under MPL2 or replace GPL2 code by GPL3 code or vice versa.
More concretely:
I think all the other GPL-licensed libraries all say "version 2 or later", so they'd work with both options.
The post linker is currently a major time stealer when building. It's written in python to make use of an ELF/Dwarf library that doesn't suck (pyelftools). Unfortunately it's slow, even with pypy due to the large number of dynamic objects it needs to create. I belive that it would be much faster to have this written in C instead. The major obstacle is finding a simple elf manipulation and dwarf parsing library.
It's currently written in PHP because it was fastest for me to do. It would be nice if it was written in something else. Suggestions?
I have never had use for an automatically expanding buffer, e.g. a classic 2^n buffer that reallocates and copies its content if it needs to expand, because I always max allocate instead as I prefer code that is optimised for the worst case instead of the expected or best case. This doesn't mean that someone could find this useful and it's such a wildly adopted pattern that librcd should provide it.
This would need explicit support by segmented stack code (lwthreads.c, stack.s, maybe clang fixes).
See #19, which (hilariously) made all of issues 1-17 say they were referenced by that issue. It could be worth changing stack trace format to avoid saying #<number>
to work around this. Or we could just say that any such list ought to have been `-quoted in the first place, and wontfix this.
Suggested name: rio_tcp_establish(). It should take a host name and a port. The host name is resolved to a list of A records. It should try to connect to each A record in order (randomly) until all records have been exhausted. The function should not return unless a tcp connection has been established (using rio_tcp_conn_wait).
Librcd currently only supports x86_64 Linux. Porting to other platforms (esp. Windows) would be a large undertaking and probably break some abstractions, and is not at the moment planned. Still, opening this as a tracking issue.
The following things are Linux-specific:
64-bit specific:
Clang would need certainly patching also. (@hannes-landeholm, plz edit this comment and add some details)
Suggested version scheme: MAJOR(+rcX). The first version will be "0".
Librcd will not have minor version numbers or use the terms "beta" and "alpha" as they have become ambiguous and reenforce the idea that stability is black and white and you can pick a version and stick with instead of having a continuous upgrade cycle.
Release candidates are for testing before rolling out a new release. The final release has the "rc" suffix dropped. New releases always increment the MAJOR version number no matter how little changes has been made. A release candidate and a subsequent release may point to the exact same commit if the release was acceptable.
Example: v0, v1+rc0, v1+rc1, v1+rc2, v1, v2, v3+rc0, v3+rc1, v3, v4+rc0, v4
The point where releases are made are initially undefined but should take place at a point where librcd is stable enough to be used. Librcd will never "support" older versions, programmers should keep up to date. Newer versions may break back compatibility in interfaces and behaviour if the long term benefits outweigh the costs.
The FSTR_STACK_DECL macro is too long and makes my eyes bleed. It also a multiple assignment pattern (cancer™).
Suggested solution:
#define fstr_stack_alloc(n) ({ uint8_t _mem[n]; FSTR_PACK(_mem); })
Is the stack of the extended GCC context valid after it returns?
Librcd should use more specific eio exception classes instead of exception_io
everywhere. E.g. eof_eio
or fs_eio
seem particularly useful.
200 is currently serialized as 2e2. This is correct but unexpected and pointless. It's not usually what people expect when they just want to dump a floating point value in a quick and dirty way. We should reserve scientific notation for the big numbers.
The overhead for concurrency is currently quite large. This is mainly caused by contention from global locks that can be eliminated with hardware transactional memory when it becomes widely available. Another solution is more fine graned locking but I've only encountered dead ends so far in R&D of this.
Particularly escape codes and UTF-16 stuff.
It would be nice to replace this with some embedded dns library. In a perfect world the operating system takes care of this...
Lists don't support direct indexing and are somewhat slower; arrays are fixed-size.
SSE state saving was implemented after misunderstanding the x86_64 systemv abi and is likely not needed. Remove it from librcd and revert the related llvm patches.
Sometimes eof is expected and since eio's was introduced we can use them to distinguish the condition. This line should be changed in rio.c
:
throw("read() failed: end of stream reached", exception_io);
This will greatly simplify the implementation of rio_read_to_end
.
define_error(json, int32_t line, int32_t col, fstr_t token);
emitosis(json_error) {
err.line = line;
err.col = col;
err.token = fsc(token);
throw_em("json parsing failed, invalid token", err);
throw_em_fwd("json parsing failed, invalid token", err, e);
}
define_errore(protocol)
throw_io(e_msg, protocol_error);
throw("", exception_arg)
catch (exception_io, e) {
if_error(e, json_error) {
err.line;
} else if_error(e, parse_error) {
} else {
throw_fwd("fwd ", e->type, e);
}
if (e->error_type == parse_error) {
parse_error_t* err = e->error_data;
}
lwt_throw_exception(e);
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.