- Rust has the same memory problem as C and C++ - 11 Updates
- [Jesus Loves You] Inspirational woman - 1 Update
- The unintended consequences of the 'auto' keyword - 1 Update
- The unintended consequences of the 'auto' keyword - 3 Updates
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 20 10:56AM -0700 > As much as purists want to claim that C++ is its own independent > programming language that's completely separate and independent > from C, I don't recall anyone making that extreme claim. > the fact is that in practice something like 99% of C is > valid C++ as-is, without modification. I wouldn't try to guess the percentage. Yes, a lot of C code is valid C++. A smaller percentage of C programs are valid C++ programs. Some (probably small) percentage of C programs are valid C++ programs with different semantics. And very little *good* C code is good C++ code. > C++ doesn't allow implicitly casting between incompatible > pointer types while C does, but doing so in C is often frowned > upon in programming style guidelines.) (I'm probably going to repeat some of what others have said.) There's no such thing as "implicit casting". There are *conversions*, which can be either implicit or explicit. An explicit conversion is a cast. Other than cases involving void*, C doesn't allow implicit conversions between incompatible pointer types. It's easy to think that it does because some compilers allow such implicit conversions by default, perhaps with a warning. For example: double d; double *dp = &d; int *ip = dp; // constraint violation The conversion in the initialization of ip is a constraint violation in C, requiring a diagnostic. gcc, by default, issues a non-fatal warning -- which is permitted by the standard. I suppose you could say that C "permits" the conversion in the sense that it doesn't require the compiler to reject it -- but the same is true of syntax errors, or anything not involving a #error directive. As far as I know, the only difference between C and C++ in this area involves void* conversions. g++, unlike gcc, treats the conversion in the code above as a fatal error by default, but that's not a difference between the languages. [...] > When someone uses the term "C/C++", he's usually referring to the > overlapping parts of those languages, as well as what both languages > share in terms of behavior. [...] My problem with the term "C/C++" is that you can never be sure just what it means. It could mean "C and C++", "C or C++", "C xor C++", "the common subset of C and C++", or "the person writing this job description doesn't understand the relationship between the languages". -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 20 08:15PM +0200 On 20.04.2020 14:16, jacobnavia wrote: > morons want to leave impression that Rust claims differently. > <end quote> > The "some morons" qualifier is surely me, of course. He was surely referring to the paper's authors, claiming that they're attacking a constructed straw-man. My take: I just skimmed the article but I don't think they're doing an attack or claiming anything improper about what Rust claim. I could have overlooked some detail though. Or, I could have failed to see a larger scale implication from context that I'm not familiar with. Anyway, research that validates the obvious can be valuable. This research validates the obvious that unsafe features are unsafe. However, research that addresses non-obvious things can be /much more valuable/, like a zintillion orders of magnitude more valuable, so that the money used on this research could probably have been better spent. > [snip] - Alf |
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 19 03:55PM +0100 > for a great promise... that they can't keep. > A recent paper shows that Rust has the same problems as C or C++. > https://arxiv.org/pdf/2003.03296.pdf The first line of the summary: "Most memory-safety bugs are related to unsafe APIs or foreign function interfaces (FFIs)." An "unsafe API" is a technical term in this paper. It does not mean buggy Rust, it means calling a library that can't provide Rust's memory guarantees. -- Ben. |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 20 08:12PM +0100 On Mon, 20 Apr 2020 18:08:18 +0200 > interface functions. The only thing you need to do is a mapping from the > C types to the Rust types. > I have done that and is absolutely doable... Rust already has an FFI for C. It doesn't need another. The point is that if you call into C code then your Rust code cannot be any safer than your C code. |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 08:14PM > it means. It could mean "C and C++", "C or C++", "C xor C++", "the > common subset of C and C++", or "the person writing this job description > doesn't understand the relationship between the languages". C/C++ programmers are ones that program C++ like C ;) That means they are not using safe features of C++... -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 08:16PM > Rust already has an FFI for C. It doesn't need another. The point is > that if you call into C code then your Rust code cannot be any safer > than your C code. In Rust, you barry unsafe code in library, and then do all the work in safe level. If library has a bug it has a bug ;) -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 20 09:38PM +0100 On Mon, 20 Apr 2020 20:16:57 GMT > > than your C code. > In Rust, you barry unsafe code in library, and then do all the > work in safe level. If library has a bug it has a bug ;) Well, that's what you do in Haskell and other "safe" languages with a C FFI. In Rust you can do some of it in unsafe Rust. Of course if the posting which began all this is correct, then "Haskell has the same memory problem as C and C++". After all, as a minimum it has to call into services provided by the OS with (in Unix-like OSes) C linkage. Errrr ... . |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 08:51PM > has the same memory problem as C and C++". After all, as a minimum it > has to call into services provided by the OS with (in Unix-like OSes) C > linkage. Errrr ... . ADA has same problem as well... -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 20 02:20PM -0700 On 4/20/2020 1:14 PM, Melzzzzz wrote: > C/C++ programmers are ones that program C++ like C ;) > That means they are not using safe features of C++... Indeed! Well... Check this crap out, using C++ like a C... https://github.com/ChrisMThomasson/MultiJulia/blob/master/ct_fplot_buddha_test_p0.cpp Can you get it to run and produce a rendering? ct_plane.ppm |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 09:50PM > Indeed! Well... Check this crap out, using C++ like a C... > https://github.com/ChrisMThomasson/MultiJulia/blob/master/ct_fplot_buddha_test_p0.cpp > Can you get it to run and produce a rendering? ct_plane.ppm That compiles as C ;) I meant for programs that compile as C++ only :) -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 09:51PM > Indeed! Well... Check this crap out, using C++ like a C... > https://github.com/ChrisMThomasson/MultiJulia/blob/master/ct_fplot_buddha_test_p0.cpp > Can you get it to run and produce a rendering? ct_plane.ppm Oh you used complex ;) -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 18 08:46PM +0100 > See how Christ was at work in her life, even through the > bad times, even when she had given up. > We all need that rope she talks about. Fuck. Off. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
Udo Steinbach <trashcan@udoline.de>: Apr 18 10:13AM +0200 Am 2020-04-14 um 12:03 Uhr schrieb Juha Nieminen: > The (new meaning of the) 'auto' keyword can be extremely useful in many > situations Not so many. Lets ask another point of view, a foreign, code auditor for security reasons: https://blog.fefe.de/?ts=a0cf97c9 | Therefore it is important that you can see in the code if something is a | raw pointer. But you can't see when it's all auto. Then the poor auditor | has to run after every fucking line one by one and deduce the types | himself. Then auto is a denial of service against the auditor. ... and that tools do not help then. A nice lecture in How to shoot in the own foot. -- Fahrradverkehr in Deutschland: http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 16 11:50PM +0200 On 16.04.2020 23:19, Keith Thompson wrote: >>> into a memory area representing a file header, and advances a write >>> position. > He has addressed that. He may have tried to the best of his ability. But being incompetent in an area of expertise, does not exonerate him from lying. > Your use of the word "deliberately" suggests an insight into his > thinking that I do not believe you possess. > [...] You're right, sorry. - Alf |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 16 09:57PM +0200 On 16.04.2020 20:52, Keith Thompson wrote: > Alf, I took a quick look at the posts upthread from this one, > and I didn't see an example from you. It's utterly implausible > that James would lie about something like that, Not as I've known him on Usenet. It's not the first time. I don't plonk people willy-nilly or lightly; too few people left, everybody counts. > reason to. It's possible that there's an honest disagreement about > what constitutes a valid example, or that he overlooked something. > Can you repost the example you're referring to? Two posts up: > entirely wrong (unintended) thing, for example if foo copies a value > into a memory area representing a file header, and advances a write > position. When James deliberately set out to misinterpret that as nonsense, then one post up: > dependency I sketched was how many bytes it would write and advance a > write position, but there are infinitely many other reasonable such > dependencies in C++. - Alf |
Christian Gollwitzer <auriocus@gmx.de>: Apr 18 07:14PM +0200 Am 17.04.20 um 17:34 schrieb Ben Bacarisse: > It may be simpler to fall into the trap in that case, but there are so > many others (~42_i16, 42_i16 + 10, 42_i16 << 1, printf("...", 42_i26)) > that knowing the underlying truth really helps. I've designed a Matlab-like language, and the integer promotion rules also got me thinking. In the end I concluded that the base integer type (like int in C++) should be disctinct from the fixed-widths types and treated as an ideal integer. i.e., even if int== int32_t, the type promotion should not widen smaller types in this case. Therefore (in my language): auto x = -42i16; // x is -42i16 // unary - is defined for int16_t -> int16_t auto i = x + 1 // i is -41i16 // no promotion, because int is special auto j = x + 1i32; // j is -41i32 // promoted because int32_t has more bits than int16_t uint8_t byte=0; auto t = byte - 1; // t is 255u8 auto u = byte - 1i32; // u is -1i32 Christian |
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment