On 2/18/2018 6:52 PM, Jonathan M Davis wrote:
On Sunday, February 18, 2018 18:26:25 Walter Bright via Digitalmars-d wrote:
It's your mail client that is doing it. Not the NNTP software.
As I pointed out in another post, mailman currently puts both the poster's
e-mail address and the mailing
On 2/18/2018 5:39 PM, Manu wrote:
Incidentally, why on earth are peoples personal email addresses even
in the mail header?
That's usually configurable. Most people set it so it's a fake address.
It should be impossible for gmail to reply-all to
peoples private emails, because they shouldn't
On 2/18/2018 5:34 PM, Manu wrote:
Apparently gmail has a new trick... reply to thread == reply-all.
That's never happened before.
Can the forum software strip out the HTML if it detects it in the
post? I'm astonished this isn't a bigger problem; surely gmail is the
worlds most popular mail
On 2/18/2018 1:17 PM, Martin Nowak wrote:
Best solution, write a custom Int type that doesn't use C's horrible
promotion rules.
I've long wanted some SafeInt library that doesn't silently promote and
supports saturation, overflow, and errors.
Doesn't
Just replying to the n.g. would be fine, no need to cc me on email and cc the
mailing list.
Also, your postings are double size again - html and plain text. Just the plain
text, please.
On 2/18/2018 11:26 AM, Manu wrote:
and most lines get 3-4 times longer because of these casts...
I'm curious, can you please post an example?
On 2/18/2018 11:21 AM, Guillaume Piolat wrote:
D used to not promote integer like C in the case of -short, -byte, ~ubyte etc.
Which is a strange discrepancy as all other integer arithmetic are the same.
It was a bug, plain and simple. Whether it was always there, or was
inadvertently
On 2/17/2018 7:04 AM, Martin Nowak wrote:
Let's pull the plug, I think everybody agrees that we have more important issues
than maintaining d.chm and dman (which hasn't been shipped since 2.076 anyhow).
Consider both tools as offered for adoption (as an external service or
download).
On 2/16/2018 2:30 PM, kinke wrote:
on behalf of the LDC team, I'm glad to announce the first beta for LDC 1.8.
Congratulations!
On 2/10/2018 4:35 AM, Timon Gehr wrote:
In summary, the issue is that there is only one 'inout' and therefore it is not
properly lexically scoped. It is a bit like having a language where all
variables are implicit function parameters and they all have the same, global,
name. This sort of
On 2/13/2018 3:35 PM, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread today and I thought
this is an excellent opportunity to revive my blog and finally write an article
showing why I like D so much:
On 2/13/2018 5:11 PM, David Nadlinger wrote:
On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote:
David (aka klickverbot) is a longtime D contributor […]
… who is slightly surprised at the amount of media interest this has attracted.
;)
— David
You shouldn't be surprised.
On 2/12/2018 8:33 PM, Nick Sabalausky (Abscissa) wrote:
I know another Ali I've tried to turn onto D, but he's pretty happy with Python.
Oh, well.
I don't think he deserves the name Ali :-)
On 2/12/2018 6:47 PM, rikki cattermole wrote:
On 13/02/2018 2:42 AM, Ali Ali wrote:
where is your pic? that will clear it up (and make you more well known ;-)
Ali Çehreli is part of the D Language Foundation.
Well known has already happened.
Ali also wrote "Programming in D: Tutorial and
On 2/12/2018 12:35 PM, Ali wrote:
It is more how you can improve a C code based, by incrementally integrating D
without loosing performance, or control
Yes, with the focus on "incrementally".
On 2/12/2018 4:47 PM, Ali Çehreli wrote:
Nothing serious but in case you are confused, there are at least three separate
and awesome Alis frequenting these newsgroups. :)
We can definitely use some more awesome Alis!
On 2/12/2018 12:23 PM, Jacob Carlborg wrote:
Here you go [1]. It's a bit outdated now, from 2013, but it worked back then.
The last dstep commit was November 2017.
[1]
https://github.com/jacob-carlborg/dmd/commit/2837d340c065cc2bf3f0a83cb96c4d9f22fb3a30
I take it dstep spawns the clang
On 2/12/2018 8:25 AM, Patrick Schluter wrote:
C is currently at [C11].
[C11]: https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29
Yes, you're right. I haven't paid any attention to C11 :/
The array bounds checking interface,
On 2/11/2018 8:59 PM, Nick Sabalausky (Abscissa) wrote:
Though I do realize that's not likely to happen. It's not as if I'm saying "hey,
go do this". All I'm really saying is "I like this idea, I'm in favor of it, and
it's worth being open to." Not much more than that.
> "That's a reasonable
On 2/11/2018 6:26 PM, Elie Morisse wrote:
Wow, you converted DMC++'s front-end to D?
Yes, it's just frustrating for me to work on C++ code anymore. :-)
To chime in on that, Calypso i.e the LDC+Clang equivalent of what you described
isn't dead (it just revived a few weeks ago from a long
On 2/11/2018 5:43 PM, timotheecour wrote:
It doesn't leave anything in Ddoc either, so that's not a viable workaround if
that comment is intended to be a DDoc.
You're right that this will never be intrepreted as a Ddoc comment. But I infer
that this resolves the non-Ddoc case?
As for Ddoc
On 2/8/2018 7:06 PM, Timothee Cour wrote:
/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
EOS"/
Easy:
mixin template comment(string s) { }
mixin
On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote:
That's the same exact reason most languages don't have most of the nice things
in D, like separators for numeric literals: Because they're not strictly
necessary. But if D had never been willing to improve the state of the art by
not
On 2/11/2018 3:01 PM, Timothee Cour wrote:
It's about `line coverage` vs `branch coverage` (see exact definition
in linked article),
Ok, I see now, thanks for your patience and the clarification.
that difference is very large in practice.
Only if one cares about the percentage metric.
On 2/11/2018 2:16 AM, Russel Winder wrote:
Confirmatory evidence is that Rust does the same thing.
D has an outsized influence that extends way beyond just D users :-)
Consider all the D features that somehow were "completely independently"
discovered years later by C++!
Even little ones
On 2/11/2018 1:55 PM, Timothee Cour wrote:
I think you're missing my main point: it's explained here
https://www.ncover.com/support/docs/extras/code-coverage/understanding-branch-coverage
but the gist is that line based coverage is over-counting:
```
if(A)
// 100 lines of code
else
// 1
On 2/11/2018 6:09 AM, Steven Schveighoffer wrote:
On 2/8/18 3:49 PM, Walter Bright wrote:
That would be a language change proposal or bug report. By all means, please
do so.
https://issues.dlang.org/show_bug.cgi?id=18420
Good!
I also notice that hex strings are not simply equivalent
On 2/5/2018 11:32 AM, Timothee Cour wrote:
just filed https://issues.dlang.org/show_bug.cgi?id=18377:
`dmd -cov -run main.d` shows 100% coverage; this is misleading since a
branch is not taken:
```
void main(){
int a;
if(false) a+=10;
}
```
Consider how -cov works today:
2| x = 3;
On 2/9/2018 11:13 AM, Manu wrote:
1. Storage class as a concept separate to the type;
void test() {
int x;
static int y;
typeof(x) != typeof(y) ???
}
On 2/10/2018 7:27 PM, Jonathan M Davis wrote:
And it's already kind of silly
that we have as many comment types as we do.
Even more comment types implies we don't know what we're doing :-(
On 2/10/2018 6:28 PM, Timothee Cour wrote:
all these workarounds are rather ugly; the proposed syntax works all
the time (user can just pick a EOC token not in comment) and is analog
to existing D heredoc strings, so nothing surprising there.
Would PR's be accepted?
You'll need to make a
On 2/8/2018 7:06 PM, Timothee Cour wrote:
/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
EOS"/
There isn't any commenting scheme that won't trip you up with certain
On 2/10/2018 7:14 AM, Dmitry Olshansky wrote:
RC is a form of GC.
Pedantically, yes. But common usage regards the two as disjoint, and it's
inconvenient to treat RC as a subset of GC when discussing tradeoffs between the
two. Nobody bothers with s/GC/GC excluding RC/.
On 2/9/2018 1:48 PM, Jonathan M Davis wrote:
If I were
doing all of my personal projects n C++, I don't know how many would be unit
tested.
I know how many. Zero.
On 2/9/2018 6:49 AM, Jonathan M Davis wrote:
The amazing thing is when a programmer tries to argue that having unit tests
makes your code worse - not that they take too long to write or that they
don't want to bother with them or any that - that they somehow make the code
worse.
It's not
On 2/9/2018 6:01 AM, Atila Neves wrote:
Unit tests are a great idea, right? Try convincing a group of 10 programmers who
have never written one and don't know anyone else who has. I have; I failed.
Unit tests are one of the great success stories of D. I believe it was a success
because it was
On 2/9/2018 6:11 AM, Atila Neves wrote:
It's easy enough to create std package like this:
module std;
public import std.algorithm;
//...
Yes, but I suspect that'll be a large negative for compile speed for smallish
programs.
On 2/9/2018 1:14 AM, meppl wrote:
let's say python is supposed to offer slow execution. So, python doesn't prove
reference counting is fast (even if it is possible in theory). D on the other
hand provides binaries who are expected to execute fast.
I believe it has been shown (sorry, no
On 2/8/2018 11:51 AM, bachmeier wrote:
The developers working on .NET had the opportunity to learn from Java, yet they
went with GC.[0] Anyone that says one approach is objectively better than the
other is clearly not familiar with all the arguments - or more likely, believes
their problem is
On 2/8/2018 10:42 AM, Steven Schveighoffer wrote:
On 2/8/18 1:25 PM, Walter Bright wrote:
"abc" is an array (it's an immutable(char)[]). There's no reason why
['a','b','c'] should be different than "abc" (other than the hidden null
character, which is irrelevant
On 2/8/2018 10:49 AM, Steven Schveighoffer wrote:
On 2/8/18 1:42 PM, Ralph Doncaster wrote:
On Thursday, 8 February 2018 at 18:31:06 UTC, Walter Bright wrote:
db 0ffdeh,0ffadh,0ffbeh,0ffefh ;
But it looks like they are all dchar, so 4x the space vs x"dea
On 2/8/2018 10:11 AM, JN wrote:
I agree, however these languages would probably have been successful even
without GC, using e.g. some form of automatic reference counting.
If reference counting would work with Java, and was better, wouldn't the Java
developers have done it decades ago?
On 2/6/2018 1:51 AM, Atila Neves wrote:
I tried Warp on a non-trivial C codebase. It didn't work (by which I mean the
code wouldn't compile with it). I don't know how clang managed to build a (for
all practical purposes I can see) bug-compatible preprocessor from scratch to
gcc, but it did and
On 2/8/2018 5:26 AM, Steven Schveighoffer wrote:
The extra data in the object file comes from the inclusion of the hexStringImpl
function, and from the template parameter (the symbol
_D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in there as well,
which will always be larger than
On 2/8/2018 7:07 AM, Steven Schveighoffer wrote:
My concern in the hexString case is the sheer requirement of CTFE for something
that is so easy to do in the compiler, already *done* in the compiler, and has
another form specifically for hex strings (the "\xde\xad\xbe\xef" form) that
isn't
On 2/8/2018 7:55 AM, JN wrote:
Citation needed on how garbage collection has been a smashing success based on
its merits rather than the merits of the languages that use garbage collection.
You can't separate the two. The Java and Go language semantics are designed
around the GC.
On 2/8/2018 9:03 AM, Dave Jones wrote:
If D had a decent garbage collector it might be a more convincing argument.
'Decent' GC systems rely on the compiler emitting "write gates" around every
assignment to a pointer. These are justified in languages like Java and Go for
which everything is
On 2/7/2018 9:45 PM, Ralph Doncaster wrote:
> While the fix is a huge improvement, it doesn't match the code generated by
the hex literals. hexString!"deadbeef" stores the null-terminated string in the
data section of the object file, while x"deadbeef" only stores 4 bytes in the
data section.
On 2/7/2018 6:39 PM, Adam D. Ruppe wrote:
On Thursday, 8 February 2018 at 01:55:19 UTC, Walter Bright wrote:
No, because their usage by druntime is nearly nonexistent.
Only because they're not supported!
Code like `0xsomething // octal something else` is found a whopping 200 times
On 2/7/2018 6:39 PM, H. S. Teoh wrote:
and hope to make a PR forit shortly.
https://issues.dlang.org/show_bug.cgi?id=18397
The bug report didn't explain what exactly in the implementation wasn't
done right. :-/
The PR does.
https://github.com/dlang/phobos/pull/6138
Another data
On 2/7/2018 1:07 PM, Nathan S. wrote:
On Tuesday, 6 February 2018 at 22:29:07 UTC, Walter Bright wrote:
nobody uses regex for lexer in a compiler.
Some years ago I was surprised when I saw this in Clojure's source code. It
appears to still be there today:
https://github.com/clojure/clojure
On 2/7/2018 4:25 PM, H. S. Teoh wrote:
Should templates like octal and hexString be in druntime instead?
No, because their usage by druntime is nearly nonexistent.
On 2/7/2018 5:03 PM, Seb wrote:
On Thursday, 8 February 2018 at 00:24:22 UTC, Walter Bright wrote:
On 2/7/2018 8:03 AM, Ralph Doncaster wrote:
As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does
On 2/7/2018 11:29 AM, Ralph Doncaster wrote:
I just did a quick check, and with DMD v2.078.1, the hexString template
increases code size by ~300 bytes vs the hex literal. So yet one more reason to
prefer the hex literals.
Indeed it does, and that is the result of a poor implementation of
On 2/7/2018 4:08 PM, Mike Franklin wrote:
Don't search for "[betterC]". Instead, use "betterC" (without the brackets).
https://issues.dlang.org/buglist.cgi?quicksearch=betterc_id=219390
We can't reliably rely on informal conventions.
I used the wrong URL. This is the right one (a keyword
On 2/7/2018 8:03 AM, Ralph Doncaster wrote:
As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.
When I tried it:
import std.conv;
void test() {
auto data = cast(ubyte[]) hexString!"deadbeef";
}
On 2/7/2018 12:13 PM, Adam D. Ruppe wrote:
even that minor hassle has hurt the use in practice, like in the druntime
examples.
hexString is in Phobos, and druntime can't use Phobos.
On 2/7/2018 8:05 AM, Adam D. Ruppe wrote:
That's just because -betterC is buggy and extremely incomplete
Can you please provide a list of these issues, and file issues that aren't on
bugzilla yet, and tag them with the betterC keyword?
I see only one:
On 2/7/2018 12:30 PM, Dmitry Olshansky wrote:
While an enjoable read, I fear we are aiming too low.
I wished to show that array bounds overflow checking is not a tractable problem
in C, i.e. you cannot make it go away by being a better programmer, and how
BetterC solves this problem.
On 2/6/2018 2:51 PM, Steven Schveighoffer wrote:
The regex problem is being solved:
https://github.com/dlang/phobos/pull/6129
Great!
On 2/6/2018 12:30 PM, Steven Schveighoffer wrote:
The regex in question I think is to ensure an email address like abc@192.168.0.5
has a valid IP address. The D1 function doesn't support that requirement.
I admit, I've never used it, so I don't know why it needs to be so complex. But
I assume
On 2/6/2018 2:03 PM, Jacob Carlborg wrote:
On 2018-02-06 21:11, Walter Bright wrote:
std.string.isEmail() in D1 was a simple function. Maybe regex is just the
wrong solution for this problem.
If I recall correctly, the current implementation of std.net.isEmail was
requested by you
On 2/5/2018 10:08 PM, H. S. Teoh wrote:
IMO, we should extend this past just one statement. It would lead to
more possibilities for optimizations and possibly other features too.
Though I understand that Walter has reservations about doing this for
some reason.
What you're asking for is data
On 2/5/2018 9:35 PM, Dmitry Olshansky wrote:
That’s really bad idea - isEmail is template so the burden of freaking slow
ctRegex
is paid on per instantiation basis. Could be horrible with separate compilation.
std.string.isEmail() in D1 was a simple function. Maybe regex is just the wrong
On 2/6/2018 3:39 AM, Seb wrote:
It's released under Creative Commons Attribution-ShareAlike 4.0 International
(CC BY-SA 4.0) by Sociomantic.
Thank you Sociomantic and the people who made this happen!
On 2/5/2018 4:08 PM, Steven Schveighoffer wrote:
I think the CPU has to do extra work to throw away that high bit, no?
So much of software relies on C integer semantics that CPU vendors have
optimized their performance for them, so no.
Except for 16 bit shorts. Shorts will exact a penalty
On 2/5/2018 4:08 PM, Steven Schveighoffer wrote:
In fact, this works in C:
char a = 1;
char b = 2;
char c = a + b;
I would actually have no problem if it were this way, as you are clear in your
intention. I'm also OK with the way it is now, where it requires the cast. The
cast is generally
On 2/5/2018 3:18 PM, Timon Gehr wrote:
Neither byte nor dchar are C types.
"byte" is a C "signed char". On Posix systems, a dchar maps to wchar_t, although
wchar_t is a typedef not a distinct type. It's a bit complicated :-)
The overloading rules are fine, but byte should not implicitly
On 2/5/2018 12:45 PM, H. S. Teoh wrote:
Sticking to C promotion rules is one of the scourges that continue to
plague D;
It's necessary. Working C expressions cannot be converted to D while introducing
subtle changes in behavior.
another example is char -> byte confusion no thanks to C
On 2/5/2018 1:20 PM, Nick Sabalausky wrote:
Ouch. I guess "the real WTF" is that 2's complement leads to supporting one
value that cannot be negated. But still, I thought we had value range
propagation rules to avoid this sort of nonsense when possible (such as the
example above)?
The real
On 2/5/2018 12:06 AM, Boris-Barboris wrote:
I think that would be most logical thing to have, but that would also imply
preprocessor, or at least it's restricted subset, wich you most probably though
about as well.
Sure. I could use the Boost licensed preprocessor in DMC, or the Boost
On 2/4/2018 11:34 AM, Steven Schveighoffer wrote:
On 2/2/18 7:10 PM, Walter Bright wrote:
On 2/1/2018 6:09 AM, Steven Schveighoffer wrote:
On 1/31/18 9:58 PM, Walter Bright wrote:
On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
Where it breaks down is when you have many nested tags
On 2/4/2018 2:27 PM, Boris-Barboris wrote:
Ability to interface with C using C header files of a target library\executable
as-is. Being able to understand the interfaces your operating system provides,
described on the language it uses, is a huge criteria to pick C for your
particular task.
On 2/4/2018 12:15 PM, bpr wrote:
Personally I agree that BetterC isn't a good alternative for C programmers.
Sure, you get some benefits of D, but you will lose many benefits of C
Which benefits of C are lost?
I'll chime in a bit on that. I recently converted the Digital Mars C++ front end
On 2/2/2018 7:06 AM, Benny wrote:
Other languages have slogans, they have selling points.
When i hear Go, you hear uniformal, fast, simple syntax language.
When i hear Rust, you hear safe, manual memory management.
When i hear D, you hear ... ... ... ...
Fast code,
On 2/1/2018 6:09 AM, Steven Schveighoffer wrote:
On 1/31/18 9:58 PM, Walter Bright wrote:
On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
Where it breaks down is when you have many nested tags, and you end with )
Long ago, I adjusted my text editor so that when the cursor is placed
On 2/2/2018 11:08 AM, Russel Winder wrote:
Hummm… could it be that Andrei did not define the task appropriately,
train the person appropriately, and mentor the person appropriately.
Management has to be able to delegate and achieve required results
without doing the work themselves.
Of course.
On 2/1/2018 3:11 AM, Martin Tschierschke wrote:
Idea: There should be some kind of news ticker for all enhancements and
important decisions, maybe at first just via twitter with a special #tag
beside #dlang where all updates are announced. And a place on the homepage,
where this feed is
On 1/31/2018 3:38 PM, H. S. Teoh wrote:
A "small fry" like myself wouldn't dare
to push the merge button on changes of this kind of magnitude, since it
could have drastic consequences that I can't foresee due to not having a
full grasp of the full scale of what is being changed.
On 1/31/2018 6:14 PM, Jonathan M Davis wrote:
I have to wonder if my settings are right. I've never noticed any color in
error messages. Messing around with some errors right now, the only color I
see is that "Error:" is in red, and some of the text is bolded, so it's
white instead of the grey
On 1/31/2018 5:58 PM, H. S. Teoh wrote:
cosmetic features.
I tough lesson I've learned is that cosmetics matter, a lot. Sometimes much more
than substance. There's no getting away from it.
On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
Where it breaks down is when you have many nested tags, and you end with )
Long ago, I adjusted my text editor so that when the cursor is placed on ), the
matching ( is found. Ditto for { }, [ ], < >, and #if/#elif/#else/#endif (!).
It's
On 1/31/2018 1:19 PM, H. S. Teoh wrote:
I'd rather stick with just B
dmd -color=off file.d
On 1/31/2018 11:59 AM, Seb wrote:
... and Mike did put _a lot_ of effort in pushing colorful error messages:
Yes, and he did a nice job of it.
The results are attractive, worthwhile, and resolves a specific complaint people
had about dmd's error messages.
On 1/31/2018 4:19 PM, Amorphorious wrote:
[...]
Don't berate other forum members.
https://www.reddit.com/r/programming/comments/7udfs4/is_anyone_replacing_c_with_d/
On 1/31/2018 5:54 AM, Jack Stouffer wrote:
On Wednesday, 31 January 2018 at 07:56:37 UTC, Andrew Benton wrote:
E.g. three compilers
Every other compiled language (and a lot of scripting ones) uses the fact of
multiple compilers for the language as a sign of adoption and ecosystem growth.
On 1/30/2018 1:02 PM, H. S. Teoh wrote:
Where's C++'s "enormous performance advantage?" I'm not seeing it,
except in this article, and, presumably, in the author's imagination.
I know C, C++, and D code generation semantics. There is only one case where
C/C++ can fundamentally generate
On 1/28/2018 12:36 AM, H. S. Teoh wrote:
Is there a practical use case for which this is actually useful?
Generic code, where a member function doesn't need the instance to perform its
task.
On 1/28/2018 12:05 AM, Jonathan M Davis wrote:
As to _why_ it works, I don't know - it seems like a bad idea to me - but it
does.
It's so your code needn't care whether it is a static member or not, just the
implementer of the class needs to care.
On 1/25/2018 10:21 AM, Benjamin Thaut wrote:
So I was thinking to myself: Is it really a good idea to lower string switches
to a template if it results in such symbols? This symbol alone takes 17815 Bytes.
If we think this is a good idea, should we rewrite this particular string switch
to use
On 1/24/2018 11:18 AM, Timothee Cour wrote:
__TIMESTAMP__ is pretty useless:
`string literal of the date and time of compilation "www mmm dd hh:mm:ss "`
eg:Wed Jan 24 11:03:56 2018
which is a weird non-standard format not understood by std.datetime.
It's the format emitted by the Standard
On 1/24/2018 9:04 PM, Mike Franklin wrote:
On Thursday, 25 January 2018 at 04:59:55 UTC, Mike Franklin wrote:
Yes, ROM is at address 0. Address 0 contains the initial stack pointer. So
you read address 0, dereference it, and then do your damage.
This is from the "what were they thinking"
On 1/24/2018 8:31 PM, Mike Franklin wrote:
On Thursday, 25 January 2018 at 04:01:47 UTC, Mike Franklin wrote:
"The initial stack pointer and the address of the reset handler must be
located at 0x0 and 0x4 respectively."
On 1/23/2018 7:22 PM, Jonathan M Davis wrote:
We need to do that anyway for the overly large
objects (and unfortunately don't last I heard).
I put a limit in at one time for struct/class sizes to prevent this issue, but
got a lot of pushback on it and it was reverted.
Perhaps we can revisit
On 1/23/2018 6:28 PM, Mike Franklin wrote:
I think you need to get involved in programming microcontrollers again because
the landscape has changed drastically. The microcontrollers I use now are more
powerful than PCs of the 90's.
Ok, but are these devices with 0 being a valid address?
It
On 1/23/2018 4:42 PM, Mike Franklin wrote:
That's what kindof ticks me off about this "null is memory safe" argument; it
seems to be only applicable to a specific platform and environment.
It's an extremely useful argument, though, as modern computers have virtual
memory systems that map 0 to
On 1/17/2018 7:22 PM, deadalnix wrote:
Reading this again, I think there is a bit of a misunderstanding. Only
cent/ucent took me ~1h to implement. The rest is more complex. That being said,
having cent/ucent would unlock a great deal of performance for crypto libraries,
and this is where the
On 1/14/2018 6:55 AM, Q. Schroll wrote:
How is (1, 2) different from [1, 2] (static array)?
It's a very good question. It's corollary is how is (1, 2) different from
struct S { int a, b; }
It does turn out that int[2] is structurally (!) the same as struct S. This is a
property I've taken
On 1/14/2018 10:17 AM, Timon Gehr wrote:
It's inherited from C, where all struct instances have size at least 1. (Such
that each of them has a distinct address.)
There are some peculiarities with that, like with multiple inheritance sometimes
the size really is zero :-)
901 - 1000 of 15506 matches
Mail list logo
