|
Plorkyeran posted:I think the suggested limit of 50 characters for the subject line is overly short (especially when you're doing things like putting ticket numbers in the subject), but if you're going way over it then you've probably failed to actually write a subject line and should put most of that in the body. [artbuild] [engine] [jira-420] Fix crash whe...
|
#
?
Jul 5, 2020 06:18
|
|
|
|
| # ? Jun 3, 2024 06:44 |
|
|
zergstain posted:Is that some new syntax? It looks like you are declaring a function called &&() as opposed to operator&&(). No, it is supposed to have the operator part, but I cut it out by mistake when simplifying the signature  The original signature looks like this C++ code:-------------------------- Ola posted:Thank you, very interesting example! If it's easy to use and works well, obviously no problems. But the topic did come up as variadic being harder to handle than non-variadic. And the case you illustrate doesn't have to be variadic to solve the usefulness of having an arbitrary number of matchers: A single matcher can be a list of one matcher. The && or || or other operators concatenate lists of matchers according to appropriate rules, then return lists of matchers. Obviously these get evaluated before the function call. The function called which deals with matching takes two arguments, something to be matched and a list of matchers. No need for arbitrary amounts of arguments, no need for variadics. Xarn posted:So far so good, the type even has a base class that could in theory be used to hold it in a single-type container... except that loses access to match, because you obviously cannot have templated virtual member functions. So, if you are to store multiple matchers like this (e.g. when you are constructing a generic MatchAll matcher), and use them to do matching, you have to keep around their actual types.
|
|
#
?
Jul 5, 2020 08:22
|
|
|
Ola posted:Yeah, I definitely missed that part, because I wasn't rubbing my fingers and sniffing the finer grains of the stupid bullshit. wow, that's an amazing amount of circular reasoning and bullshit stats
|
|
#
?
Jul 5, 2020 08:24
|
|
|
IBM punch cards were 80 characters wide and teletypes followed that example. 72 is also an IBM-ism as far as I know. The FORTRAN reference hinted at it, but at least the last time I was forced to use a z Series mainframe with the godawful text interface, 8 characters between the left and right gutters were taken up with things like line numbers and other control chars. This was writing PL/I and JCL, not FORTRAN. Why the world is still stuck on this limit, I have no idea. Blocks of text are generally easier to read than long lines with continuation, so I guess an arbitrary traditional limit is better than nothing?
|
|
#
?
Jul 5, 2020 08:41
|
|
|
https://baymard.com/blog/line-length-readabilityquote:The optimal line length for your body text is considered to be 50-60 characters per line, including spaces (“Typographie”, E. Ruder). Other sources suggest that up to 75 characters is acceptable.
|
|
#
?
Jul 5, 2020 09:24
|
|
|
Gaukler posted:Why the world is still stuck on this limit, I have no idea. Blocks of text are generally easier to read than long lines with continuation, so I guess an arbitrary traditional limit is better than nothing? Never underestimate the power of peer pressure from dead people.
|
|
#
?
Jul 5, 2020 15:00
|
|
|
This thread and its replies are great https://twitter.com/danluu/status/1115707741102727168
|
|
#
?
Jul 5, 2020 15:37
|
|
|
Xarn posted:No, it is supposed to have the operator part, but I cut it out by mistake when simplifying the signature I'm really not up to date on C++, so I honestly wasn't sure.
|
|
#
?
Jul 5, 2020 16:14
|
|
|
pokeyman posted:This thread and its replies are great https://twitter.com/danluu/status/1115707741102727168 I like this one the best, because the first time I read it, I thought they were joking. https://mobile.twitter.com/decivilizator/status/1115873168445644800
|
|
#
?
Jul 5, 2020 17:13
|
|
|
The whole “ideal values” thing from the Linux kernel commits is really dumb. All that data shows is that 50 characters is the most common length, not that it is “ideal,” which is something that will vary from user to user anyway. How many commits of those are just “fixed a few bugs” or “asdfghjkl” or whatever too? Make it configurable and let people define their own limits, boom, everyone’s happy.
|
|
#
?
Jul 5, 2020 17:23
|
|
|
Protocol7 posted:How many commits of those are just “fixed a few bugs” or “asdfghjkl” or whatever too? Protocol7 posted:Make it configurable and let people define their own limits, boom, everyone’s happy.
|
|
#
?
Jul 5, 2020 17:40
|
|
|
pokeyman posted:This thread and its replies are great https://twitter.com/danluu/status/1115707741102727168 Readability for general text and commit messages are different issues anyway.
|
|
#
?
Jul 5, 2020 17:53
|
|
|
Xarn posted:I like this one the best, because the first time I read it, I thought they were joking. lol "nerd-driven studies" I only take advice on typography from high school football players. It is quite hard to hear their advice clearly from the inside of a locker though.
|
|
#
?
Jul 5, 2020 18:20
|
|
|
Protocol7 posted:The whole “ideal values” thing from the Linux kernel commits is really dumb. All that data shows is that 50 characters is the most common length, not that it is “ideal,” which is something that will vary from user to user anyway. Zero of them.
|
|
#
?
Jul 5, 2020 18:30
|
|
|
i care about line length and definitely am not a nerd
|
|
#
?
Jul 5, 2020 18:35
|
|
|
zergstain posted:Why 72? I thought 80 was the width of those dumb terminals from the 1970s. Back when I was doing COBOL and FORTRAN on punched cards (yes, I am that old), the rightmost eight columns were reserved for sequence numbers, which you definitely wanted in case you ever dropped a box of cards.
|
|
#
?
Jul 6, 2020 00:31
|
|
|
LongSack posted:Back when I was doing COBOL and FORTRAN on punched cards (yes, I am that old), the rightmost eight columns were reserved for sequence numbers, which you definitely wanted in case you ever dropped a box of cards. wow, you must be really old I am old, today I mentioned in the 80s in front of some juniors devs, but I realized too late that they never experienced it, except maybe in pop culture. people tell me the 80s where horrible, and I don't doubt it, but for me it was the 90's that ruined everything. Us programmers must bring back some customs. For once infinite paper printers to put code into paper. .. or whatever was called these printers that printed using paper forming a single roll of pages connected in the borders forming a zig zag.
|
|
#
?
Jul 8, 2020 00:01
|
|
|
Tei posted:wow, you must be really old Why are you printing out many many pages of code?
|
|
#
?
Jul 8, 2020 00:06
|
|
|
Tei posted:Us programmers must bring back some customs. For once infinite paper printers to put code into paper. .. or whatever was called these printers that printed using paper forming a single roll of pages connected in the borders forming a zig zag. Continuous feed printer
|
|
#
?
Jul 8, 2020 00:17
|
|
|
a hot gujju bhabhi posted:Why are you printing out many many pages of code? In the late 90s/early 200s when I was in junior high/high school I printed out pages upon pages of Z80 assembly code for TI-82 games, so I could read it when I wasn't at a computer. I would write code on paper too.
|
|
#
?
Jul 8, 2020 00:45
|
|
|
more falafel please posted:In the late 90s/early 200s when I was in junior high/high school I printed out pages upon pages of Z80 assembly code for TI-82 games, so I could read it when I wasn't at a computer. I would write code on paper too. This but tibasic Only game I’ve ever “published”
|
|
#
?
Jul 8, 2020 00:51
|
|
|
Tei posted:Us programmers must bring back some customs. For once infinite paper printers to put code into paper. .. or whatever was called these printers that printed using paper forming a single roll of pages connected in the borders forming a zig zag. Hell yeah, I'm on board with bringing back dot matrix printers and continuous form paper.
|
|
#
?
Jul 8, 2020 00:51
|
|
|
a hot gujju bhabhi posted:Why are you printing out many many pages of code? are you really going to read it on a cramped fuzzy little terminal screen, with those cathode rays probably giving you eye cancer? or do you just never do code review?
|
|
#
?
Jul 8, 2020 00:57
|
|
|
https://twitter.com/jfbastien/status/1280709082626666498
|
|
#
?
Jul 8, 2020 21:41
|
|
|
It's "could be called" right? There's multiple reasons why malloc() could return nullptr, for one thing, and func(p) may call free(p). With sz staying the same, it's entirely possible that malloc() would return the same pointer that was just freed.
|
|
#
?
Jul 8, 2020 22:28
|
|
|
Isn't invoking pointer provenance overcomplicating things there? A simplified version of that code is fairly obviously UB:code:
|
|
#
?
Jul 8, 2020 22:32
|
|
|
Plorkyeran posted:Isn't invoking pointer provenance overcomplicating things there? A simplified version of that code is fairly obviously UB: I guess comparing a pointer (the address itself) is use-after-free? That seems weird, but ok.
|
|
#
?
Jul 8, 2020 22:34
|
|
|
more falafel please posted:I guess comparing a pointer (the address itself) is use-after-free? That seems weird, but ok. Yes, in the C abstract machine a pointer points to an object which has an address, and not to an address. Once the object is gone, trying to read the object's address is a use-after-free. Wait, I guess I said it was pointless to invoke pointer provenance and then went on to describe pointer provenance.
|
|
#
?
Jul 8, 2020 22:39
|
|
|
Plorkyeran posted:Wait, I guess I said it was pointless to invoke pointer provenance and then went on to describe pointer provenance.  The better question here is, what is the provenance of a malloc-returned nullpointer? If it is universal, then the last call could be called, if malloc fails both times. If every call to malloc has unique provenance (IIRC Clang believes this), even for nullptrs, then it can never be called. Xarn fucked around with this message at 23:04 on Jul 8, 2020 |
|
#
?
Jul 8, 2020 22:59
|
|
|
The clang justification for that optimization is some amusing pedantry. - When compiled without ffreestanding, clang knows what malloc() does. - Specifically, it knows that that its specification does not require any visible side-effects - It is therefore permissible to swap in a different malloc()/free() implementation for that one pair. - If it can prove you never access through the returned pointer, the new implementation never actually needs to allocate memory - New implementation never fails on any size allocation so it never returns NULL
|
|
#
?
Jul 9, 2020 00:17
|
|
|
Soricidus posted:are you really going to read it on a cramped fuzzy little terminal screen, with those cathode rays probably giving you eye cancer? or do you just never do code review? He said he wants to bring it back, which implies he wants to print out many pages of code today. If he's using a fuzzy little terminal screen today then I guess I get it.
|
|
#
?
Jul 9, 2020 00:48
|
|
|
Aren't you, by casting to uintptr_t, saying treat this as an unsigned integer, which would avoid UB in that case? I really had no idea simply looking at the value of an invalid pointer was UB, I thought you'd have to dereference it. Shows how much I know about C. Edit: Actually the value is copied to ip before func() is called, and ip is just an unsigned integer with the same width as a pointer on the target platform. zergstain fucked around with this message at 01:21 on Jul 9, 2020 |
|
#
?
Jul 9, 2020 01:16
|
|
|
So if I do void* p = malloc(sz); uintptr_t ip = (uintptr_t)p; free(p); Now both p and ip have indeterminate values? How about if I itoa ip before freeing the pointer, does the string end up with an indeterminate value?
|
|
#
?
Jul 9, 2020 02:23
|
|
|
UB begets UB, like the fruit of a poisonous tree
|
|
#
?
Jul 9, 2020 02:26
|
|
|
Jabor posted:So if I do My understanding is that UB isn't a per-line or per-variable or per-function thing. Once your program has any UB, the entire program's behavior is undefined.
|
|
#
?
Jul 9, 2020 02:36
|
|
|
If I don't actually do anything with p after freeing it, then p is not causing the program as a whole to exhibit UB. Is it UB if I do something with ip after freeing p? What about if I do something with the string I created using atoi while it was still valid?
|
|
#
?
Jul 9, 2020 02:44
|
|
|
That code seems fine to me. The integer is not a pointer. Original tweet is 'could be called' because there is no guarantee that the two calls return different values. code:
|
|
#
?
Jul 9, 2020 02:56
|
|
|
There is a class of optimizations with the following form. There is an object: perhaps you've allocated it with malloc, or perhaps it's a local or global variable. The compiler can see all the ways in which you use that object. If those uses look like [insert condition here], the compiler can [insert optimization here]. This is an extremely important class of optimizations. Without it, you can't even turn int x = 5; foo(); bar(x); into foo(); bar(5);. If you cannot do these optimizations, the compiler can do almost nothing with your code once it involves memory of any kind. These optimizations all assume that you cannot just "guess" a pointer. This is tricky, because of course you can just "guess" a pointer. A pointer has a fixed-size representation in memory, and you can just plop down random bits into that representation and have a 1/N chance of ending up with the right value. More plausibly, you might have some clever way to figure out what the address of an object must be without just copying the pointer. For example, you could figure out the size of a stack frame and then prove that other objects occupy all the other memory. Or you could do a careful series of pointer comparisons to extract the bits of the pointer one by one. Or you could just know that the object has address 0x10107ffe6 in the current build. The point is that the compiler must have some way to say that you aren't allowed to have done that even if you show up with an address that, sure enough, happens to coincide with an object of the right type, because otherwise the compiler might as well be a macro assembler. (Interestingly, there is a hardware proposal called CHERI in which the actual representation of pointers is special beyond what's expressible in that ordinary memory. It is extremely problematic. But it would potentially change the game here if anyone ever adopted it.) This is what provenance is about. The idea is that if you take a pointer to an object that happens be at address 0x10107ffe6 and you cast it to an integer and you cast it back, that is fundamentally different from getting a packet from the gods containing the string "0x10107ffe6" and parsing out that integer value and casting to pointer type. That has to be the idea. It is the only way anything works.
|
|
#
?
Jul 9, 2020 03:07
|
|
|
Jabor posted:If I don't actually do anything with p after freeing it, then p is not causing the program as a whole to exhibit UB. Strictly UB yes, not because it's guaranteed to compile or not, but just undefined. Imagine if you were reading bytes from urandom instead of memory addresses. Depending on the way you use them the program may still work, but converting random bytes to a string doesn't make them more meaningful, they're still opaque to you. edit: efb but also glad someone else compared to randomness
|
|
#
?
Jul 9, 2020 03:26
|
|
|
|
| # ? Jun 3, 2024 06:44 |
|
|
xtal posted:Strictly UB yes, not because it's guaranteed to compile or not, but just undefined. Imagine if you were reading bytes from urandom instead of memory addresses. Depending on the way you use them the program may still work, but converting random bytes to a string doesn't make them more meaningful, they're still opaque to you. The program has some unpredictable output. It does not have undefined behavior. code:An undefined behavior program might: - Also print that - Crash - Print nothing - Infinite loop - Return some other exit code etc...
|
|
#
?
Jul 9, 2020 03:33
|
|