On Friday, 5 February 2016 at 20:35:16 UTC, Chris Wright wrote:
On Fri, 05 Feb 2016 10:04:01 -0800, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Feb 05, 2016 at 07:31:34AM +, tsbockman via
Digitalmars-d wrote:
On Friday, 5 February 2016 at 07:05:06 UTC, H. S. Teoh wrote:
OK, probably I'm
On Fri, 05 Feb 2016 10:04:01 -0800, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Feb 05, 2016 at 07:31:34AM +, tsbockman via Digitalmars-d
> wrote:
>> On Friday, 5 February 2016 at 07:05:06 UTC, H. S. Teoh wrote:
>> >On Fri, Feb 05, 2016 at 04:02:41AM +, tsbockman via Digitalmars-d
>> >wr
On Fri, Feb 05, 2016 at 07:31:34AM +, tsbockman via Digitalmars-d wrote:
> On Friday, 5 February 2016 at 07:05:06 UTC, H. S. Teoh wrote:
> >On Fri, Feb 05, 2016 at 04:02:41AM +, tsbockman via Digitalmars-d
> >wrote:
> >>On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote:
> >>>On
On 5/02/2016 10:07 PM, tsbockman wrote:
I think it makes sense (when actually linking to C) to allow stuff like
druntime's creative use of overloads. The signatures of the two
bsd_signal() overloads are compatible (from C's perspective), so why not?
However, multiple `extern(C)` overloads that
On Friday, 5 February 2016 at 10:49:50 UTC, Daniel Murphy wrote:
Currently D allows overloading extern(C) declarations, see
https://issues.dlang.org/show_bug.cgi?id=15217
Checking for invalid overloads with non-D linkage is covered
here:
https://issues.dlang.org/show_bug.cgi?id=2789
But neith
On 5/02/2016 11:03 AM, tsbockman wrote:
The compiler cannot (in the general case) verify that `extern(C)`
declarations are *correct*. What it could do, though, is verify that
they are *consistent*.
If the same `extern(C)` symbol is declared multiple places in the D
source code for a program, th
On Friday, 5 February 2016 at 07:05:06 UTC, H. S. Teoh wrote:
On Fri, Feb 05, 2016 at 04:02:41AM +, tsbockman via
Digitalmars-d wrote:
1) Insert that information (together with what file and line
number it
came from) into a big list in a temporary file.
2) After all modules have been compil
Let me add to this that the superior approach is to compile to an
intermediated high level format that retains type information. I
guess this is where Rust is heading.
It just isn't possible with C semantics to make a reasonable
version of that, since the language itself is 90% unsafe and just
On Friday, 5 February 2016 at 01:10:53 UTC, tsbockman wrote:
All along I have been saying this is something that *compilers*
should warn about. As far as I can recall, I never suggested
using linters, sanitizers, changing the C standard - or even
compiler plugins.
Well, compilers "should" onl
On Friday, 5 February 2016 at 07:15:56 UTC, H. S. Teoh wrote:
This would break shared library upgrades that do not change the
ABI.
Plus, it doesn't fix wrong linkage at runtime, because the
dynamic linker is part of the OS and the D compiler has no
control over what it does beyond the standar
On Friday, 5 February 2016 at 07:05:06 UTC, H. S. Teoh wrote:
On Fri, Feb 05, 2016 at 04:02:41AM +, tsbockman via
Digitalmars-d wrote:
On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote:
>On Fri, 05 Feb 2016 01:10:53 +, tsbockman wrote:
What information, specifically, is the
On Fri, Feb 05, 2016 at 04:39:13AM +, tsbockman via Digitalmars-d wrote:
[...]
> Thanks for the explanation. That does sound basically the same as the
> C issue.
>
> Since .di files are normally generated automatically, this seems like
> an easily solvable problem:
>
> 1) When compiling a lib
On Fri, Feb 05, 2016 at 04:02:41AM +, tsbockman via Digitalmars-d wrote:
> On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote:
> >On Fri, 05 Feb 2016 01:10:53 +, tsbockman wrote:
> >The compiler doesn't have all the information you need. You could add it
> >to the build system o
On Friday, 5 February 2016 at 06:05:49 UTC, Chris Wright wrote:
It doesn't know what targets I'm ultimately creating, and it
doesn't know what files have been modified that I'm about to
compile (but haven't compiled yet).
Example 1:
I compile one .c file referencing a function:
void foo(int);
On Fri, Feb 05, 2016 at 12:14:11AM +, tsbockman via Digitalmars-d wrote:
[...]
> This isn't even a particularly expensive (in compile-time costs) check
> to perform anyway; all that is necessary is to store a temporary table
> of symbol signatures somewhere (it doesn't need to be in RAM), and
>
On Fri, 05 Feb 2016 04:02:41 +, tsbockman wrote:
> On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote:
>> On Fri, 05 Feb 2016 01:10:53 +, tsbockman wrote:
>> The compiler doesn't have all the information you need. You could add
>> it to the build system or the linker as well as
On Friday, 5 February 2016 at 04:25:09 UTC, Adam D. Ruppe wrote:
On Friday, 5 February 2016 at 01:33:14 UTC, tsbockman wrote:
As to the ".di" stuff - I've not used them. Care to educate
me? How can they cause similar problems?
Well, technically, a .di file is just a .d file renamed, but it
te
On Friday, 5 February 2016 at 01:33:14 UTC, tsbockman wrote:
As to the ".di" stuff - I've not used them. Care to educate me?
How can they cause similar problems?
Well, technically, a .di file is just a .d file renamed, but it
tends to have the bodies stripped out. Separate compliation is a
su
On Friday, 5 February 2016 at 03:46:37 UTC, Chris Wright wrote:
On Fri, 05 Feb 2016 01:10:53 +, tsbockman wrote:
The compiler doesn't have all the information you need. You
could add it to the build system or the linker as well as the
compiler. Adding it to the linker is almost identical to
On Fri, 05 Feb 2016 01:10:53 +, tsbockman wrote:
> All along I have been saying this is something that *compilers* should
> warn about.
The compiler doesn't have all the information you need. You could add it
to the build system or the linker as well as the compiler. Adding it to
the linker
On 2/4/2016 3:10 PM, H. S. Teoh via Digitalmars-d wrote:
The C preprocessor accepts all sorts of nasty, nonsensical things.
The preprocessor makes C++ into an inherently unreliable, unsafe programming
language. I've talked to some C++ committee members about this, about why there
is no push t
On Friday, 5 February 2016 at 01:14:05 UTC, Adam D. Ruppe wrote:
D allows that. This is why I recommend putting `static
assert(foo.sizeof == expectation);` in code that interfaces
with external things, like C code, or D .di stuff.
#include /* sqrt */
D *doesn't* allow that though - at least
On Thursday, 4 February 2016 at 22:57:00 UTC, tsbockman wrote:
The first place entry is particularly ridiculous; is there any
modern language that would make it so easy to commit such an
awful "mistake"?
D allows that. This is why I recommend putting `static
assert(foo.sizeof == expectation);
On Friday, 5 February 2016 at 00:56:16 UTC, Chris Wright wrote:
True. That works if this is baked into your compiler, or if
your compiler has plugin support. And you'd have to compile
with this plugin or the relevant options turned on by default
in order for you not to duplicate work.
On Frid
On Friday, 5 February 2016 at 00:41:52 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 5 February 2016 at 00:14:11 UTC, tsbockman wrote:
But it's 2016 and my PC has 32GiB of RAM. Why should a C
compiler running on such a system skip safety checks just
because they would be too expensive to run on so
On Fri, 05 Feb 2016 00:38:16 +, tsbockman wrote:
> On Friday, 5 February 2016 at 00:03:56 UTC, Chris Wright wrote:
>> Doing this sort of validation requires build system integration (track
>> the command line arguments that went into producing this object file;
>> find which object files are c
On Friday, 5 February 2016 at 00:50:32 UTC, tsbockman wrote:
On Friday, 5 February 2016 at 00:41:52 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 5 February 2016 at 00:14:11 UTC, tsbockman wrote:
But it's 2016 and my PC has 32GiB of RAM. Why should a C
compiler running on such a system skip safety
On Friday, 5 February 2016 at 00:14:11 UTC, tsbockman wrote:
But it's 2016 and my PC has 32GiB of RAM. Why should a C
compiler running on such a system skip safety checks just
because they would be too expensive to run on some *other*
computer?
C has to be backwards compatible, but I don't kn
On Friday, 5 February 2016 at 00:07:45 UTC, Chris Wright wrote:
Which suggests a check of this sort should be a warning rather
than an error, or perhaps that a pragma or attribute could be
offered to ignore it.
Systems languages let you go into "Here Be Dragons" territory,
but it would be nic
On Friday, 5 February 2016 at 00:03:56 UTC, Chris Wright wrote:
Doing this sort of validation requires build system integration
(track the command line arguments that went into producing this
object file; find which object files are combined into which
targets; run the analysis on that) and cos
On Thursday, 4 February 2016 at 23:59:06 UTC, H. S. Teoh wrote:
On Thu, Feb 04, 2016 at 11:47:53PM +, tsbockman via
Digitalmars-d wrote: [...]
Even so, I think that qualifies as a compiler bug or a hole in
the D spec.
Nah... while D, by default, tries to be type-safe and prevent
guffaws l
On Friday, 5 February 2016 at 00:12:07 UTC, Ola Fosheim Grøstad
wrote:
It makes perfect sense for one compilation unit to type a
parameter pointer to float and another unit to type the same
parameter as a simd-array of floats. The underlying code could
be machine language. And in machine langu
On Friday, 5 February 2016 at 00:03:20 UTC, tsbockman wrote:
If the same `extern(C)` symbol is declared multiple places in
the D source code for a program, the compiler should issue at
least a warning if the D signatures don't agree with each other.
I guess D could do it, although this is a ra
On Thursday, 4 February 2016 at 23:53:58 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 4 February 2016 at 23:35:46 UTC, tsbockman wrote:
Just because *sometimes* the source code of the other module
must be compiled independently, is a poor excuse to skip
obvious, useful safety checks *all* the t
On Thu, 04 Feb 2016 15:59:06 -0800, H. S. Teoh via Digitalmars-d wrote:
> Nah... while D, by default, tries to be type-safe and prevent guffaws
> like the above, it *is* also a systems programming language (or at
> least, that's one of the stated goals), so it does allow you to go under
> the hood
On Thursday, 4 February 2016 at 23:51:57 UTC, anonymous wrote:
We do have a lot of bindings to C libraries, though. When
there's a wrong alias in one of them, you have the same
scenario.
On 05.02.2016 00:47, tsbockman wrote:
Even so, I think that qualifies as a compiler bug or a hole in
the D
On Thu, 04 Feb 2016 23:29:10 +, tsbockman wrote:
> That explains why the linker doesn't catch it. I still don't see much
> excuse for the compiler allowing it though, beyond a desire to allow
> each module to be compiled independently.
Doing this sort of validation requires build system integ
On Thu, Feb 04, 2016 at 11:47:53PM +, tsbockman via Digitalmars-d wrote:
[...]
> You can do the same thing in D if you try, but it's not natural at all
> to use `extern(C)` for *internal* linkage of an all-D program like
> that.
>
> Any competent reviewer would certainly question why you were
On Thursday, 4 February 2016 at 23:35:46 UTC, tsbockman wrote:
Just because *sometimes* the source code of the other module
must be compiled independently, is a poor excuse to skip
obvious, useful safety checks *all* the time.
The context is a compilation system for building big software on
v
On 05.02.2016 00:47, tsbockman wrote:
You can do the same thing in D if you try, but it's not natural at all
to use `extern(C)` for *internal* linkage of an all-D program like that.
Any competent reviewer would certainly question why you were using
`extern(C)`; this scores much lower in "underha
On Thu, Feb 04, 2016 at 11:21:54PM +, tsbockman via Digitalmars-d wrote:
[...]
> Definitely. What puzzles me about the winning entry, though, is that the
> compiler and/or linker should be able to trivially detect the type mismatch
> *after* the preprocessor pass(es) are already done.
It canno
On Thursday, 4 February 2016 at 23:40:13 UTC, anonymous wrote:
You can do the same thing in D, using extern(C) to get no
mangling:
main.d:
alias float_t = double;
extern(C) float_t deref(float_t* a);
void main()
{
import std.stdio: writeln;
float_t d = 1.23;
writeln(deref(&d));
On 04.02.2016 23:57, tsbockman wrote:
http://www.underhanded-c.org/#winner
Actually, I'm surprised that this works even in C - I would have
expected at least a compiler (or linker?) warning; this seems like it
should be easy to detect automatically.
You can do the same thing in D, using extern
On Thursday, 4 February 2016 at 23:25:58 UTC, Ola Fosheim Grøstad
wrote:
In C, compilation units are completely independent, and can in
fact come from different compilers and different languages. C
is very much a system level programming language.
I should also point out that D can link to (mo
On Thursday, 4 February 2016 at 23:29:10 UTC, tsbockman wrote:
That explains why the linker doesn't catch it. I still don't
see much excuse for the compiler allowing it though, beyond a
desire to allow each module to be compiled independently.
The excuse is that C use the same mechanism for cr
On Thursday, 4 February 2016 at 23:25:58 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 4 February 2016 at 23:21:54 UTC, tsbockman wrote:
It should just see that the post-preprocessor signatures of
`spectral_contrast()` in match.c and spectral_contrast.c are
in conflict, and either issue a warnin
On Thursday, 4 February 2016 at 23:21:54 UTC, tsbockman wrote:
Definitely. What puzzles me about the winning entry, though, is
that the compiler and/or linker should be able to trivially
detect the type mismatch *after* the preprocessor pass(es) are
already done.
Linkers don't know anything a
On Thursday, 4 February 2016 at 23:24:21 UTC, Chris Wright wrote:
C linkage does zero name mangling, which is the problem. C++
introduced name mangling, so compiling with g++ would show the
error rather quickly. C99 is pretty close to C++98, but there
are enough differences that that isn't a re
On Thursday, 4 February 2016 at 23:19:20 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 4 February 2016 at 22:57:00 UTC, tsbockman wrote:
Actually, I'm surprised that this works even in C - I would
have expected at least a compiler (or linker?) warning; this
seems like it should be easy to detect
On Thu, 04 Feb 2016 22:57:00 +, tsbockman wrote:
> The annual Underhanded C Contest announced their winners today.
>
> As always, the results are very entertaining, and also an excellent
> advertisement for languages-that-are-not-C.
>
> The first place entry is particularly ridiculous; is th
On Thursday, 4 February 2016 at 23:10:23 UTC, H. S. Teoh wrote:
On Thu, Feb 04, 2016 at 10:57:00PM +, tsbockman via
Digitalmars-d wrote:
The annual Underhanded C Contest announced their winners today.
As always, the results are very entertaining, and also an
excellent advertisement for lan
On Thursday, 4 February 2016 at 22:57:00 UTC, tsbockman wrote:
Actually, I'm surprised that this works even in C - I would
have expected at least a compiler (or linker?) warning; this
seems like it should be easy to detect automatically.
AFAICT C would have complained if he had included . This
On Thu, Feb 04, 2016 at 10:57:00PM +, tsbockman via Digitalmars-d wrote:
> The annual Underhanded C Contest announced their winners today.
>
> As always, the results are very entertaining, and also an excellent
> advertisement for languages-that-are-not-C.
>
> The first place entry is particu
The annual Underhanded C Contest announced their winners today.
As always, the results are very entertaining, and also an
excellent advertisement for languages-that-are-not-C.
The first place entry is particularly ridiculous; is there any
modern language that would make it so easy to commit s
54 matches
Mail list logo
