Address of first element...



  • I'm currently porting some horrible code from PowerPC to ARM. (both linux) And I keep seeing the following:

    [code]

    memcpy((void*)&(dst[0]), (void*)&(src[0]), len);

    [/code]

    Why the address of element 0? WHY?

    And any pointer implicitly casts to void* without warning, so why the void* casts? WHY? (memcpy takes void* for the uninformed)



    I'm also finding lots of (void*) casts that shouldn't be there and are causing bugs, but that's another story. Not to mention the 3600 warnings I got.



    Good thing this software doesn't do anything safety related... oh, wait, it does! Well, failure doesn't result in immediate deaths or anything, normal operation should trigger warning systems. Reducing the chance of accidents.



  • The void cast is necessary with some really pendantic compiler switches.



  • @Daid said:

    so why the void* casts? WHY? (memcpy takes void* for the uninformed)
    The usual reason is to silence the warnings generated because the original author didn't
    #include <stdlib.h>
    , or habit because that's what they've done in the past. (I'm assuming this isn't C++ which is where the casts would be required, but then again you wouldn't normally be using those functions in C++)



  • @nexekho said:

    The void cast is necessary with some really pendantic compiler switches.
    No it's not if the compiler is at least pretending to be Standards Compliant.



  • [code]-Werror -pedantic -Wall -Wextra -Wformat=2 -Wnonnull -Winit-self -Wmain -Wmissing-include-dirs -Wtrigraphs -Wunused -Wunknown-pragmas -Wstrict-overflow=4 -Wfloat-equal -Wdeclaration-after-statement -Wundef -Wshadow -Wpointer-arith -Wtype-limits -Wwrite-strings -Wclobbered -Wconversion -Wempty-body -Wjump-misses-init -Wsign-compare -Waddress -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Winline -Winvalid-pch -Wpointer-sign -Wunsuffixed-float-constants[/code]



    We sometimes play a little game, see how many errors we get from this. ;]



  • TRWTF is <font face="Lucida Console" size="2">&(dst[0])</font>



  • @noitcif said:

    TRWTF is <font face="Lucida Console" size="2">&(dst[0])</font>

     

    IIRC if you have a local array on the stack like "int dst[10];" you have to use code like &dst[0] or you get a type mismatch, like "cannot convert int[10] to int*". I distinctly remeber being flustered about this in high school as i though that dst[i] was shorthand for (dst+i) and dst should match an int.

     

    So yeah i agree TRWTF is &(dst[0])

     



  • @esoterik said:

    IIRC if you have a local array on the stack like "int dst[10];" you have to use code like &dst[0] or you get a type mismatch, like "cannot convert int[10] to int*".


    You should just be able to use &dst in that case:

      memcpy( &dst,  &src, len);
    

    I suppose leaving the array accessor in there makes it a little more obvious as to what's going on, or a hint, anyways. Not a huge WTF, but kinda weird and more verbose than it needs to be.



  • @Daid said:

    <font face="Lucida Console" size="2">memcpy((void*)&(dst[0]), (void*)&(src[0]), len);</font>

    This is why I don't want to learn C.



  • @Daid said:

    <font size="2" face="Lucida Console">memcpy((void*)&(dst[0]), (void*)&(src[0]), len);

    </font>

    Why the address of element 0? WHY?
     

    If it's C++ rather than C, then I think taking the address of element 0 would actually be in line with Stroustrup's original desire for the language. IIRC he wasn't keen on allowing array variables to decay implicitly to pointers, and only did so to keep C programmers happy. Or something along those lines anyway.

     Not that Stroustrup is necessarily right...



  • @derula said:

    @Daid said:
    <font face="Lucida Console" size="2">memcpy((void*)&(dst[0]), (void*)&(src[0]), len);</font>

    This is why I don't want to learn C.

    It's people who haven't learnt C that tend to write crap like that in C. It's perfectly possible for that to be expressed as:

    memcpy(dst, src, len);



  • I don't know what most of these options mean, but I'd have assumed that

    @nexekho said:

    <font face="Lucida Console" size="2">-Werror -pedantic -Wall</font>

    is enough to trigger the rest?! At least those

    <font face="Lucida Console" size="2">-Wjump-misses-init -Wsign-compare</font>

    definitely sound like you should get a warning with the -Wall switch alone.



  • Every time I see C++ now, I get post-traumatic stress disorder.

    It's like that episode of Red Dwarf where they find the time machine and they go back to like the 15th century but since it's only a time machine and not a time-and-space machine they're still in the middle of nowhere and then their future selves pop in and they invite the future selves to dinner and when future-Rimmer enters their crappy-ass ship he screws up his face in disgust and goes, "can you believe we used to live like this!"

    Can you believe we used to write code like this!



  • @esoterik said:

    @noitcif said:

    TRWTF is <font face="Lucida Console" size="2">&(dst[0])</font>

     

    IIRC if you have a local array on the stack like "int dst[10];" you have to use code like &dst[0] or you get a type mismatch, like "cannot convert int[10] to int*". I distinctly remeber being flustered about this in high school as i though that dst[i] was shorthand for (dst+i) and dst should match an int.

     

    So yeah i agree TRWTF is &(dst[0])

     

    I have not had such problems, just memcpy(dst, src, len) work for me. Were you programming C++ in high school maybe it is different than C. I just used C



  • Just letting that void* return fall off into the guts of the computer is horribly irresponsible and I bet "len" isn't even a size_t!  And you shouldn't blindly trust that len is smaller that the length of dst either...

     <font face="Lucida Console" size="2">(void)memcpy((void*)&(dst[0]), (void*)&(src[0]), (size_t)len<(size_t)((sizeof(dst))/(sizeof(dst[0])))?(size_t)len:(size_t)((sizeof(dst))/(sizeof(dst[0]))));</font>

    Much better.



  • I don't know what most of these options mean, but I'd have assumed that

    nexekho:
    -Werror -pedantic -Wall

    is enough to trigger the rest?! At least those

    No, in fact it's all a bit odd and obscure. At least under GCC. Carmack recently tweeted he'd like to see it revamped and #pragma have access to the command line switches which wouldn't be too bad.



  • @nexekho said:

    I don't know what most of these options mean, but I'd have assumed that

    nexekho:
    -Werror -pedantic -Wall

    is enough to trigger the rest?! At least those

    No, in fact it's all a bit odd and obscure. At least under GCC. Carmack recently tweeted he'd like to see it revamped and #pragma have access to the command line switches which wouldn't be too bad.

    What do the compiler makers think the word "all" means?



  • It's C code. Not C++.



    In 99% of the cases src was a pointer, not something on the stack.



    -Wall turns on all normal warnings, if you want fun, you turn on -Wextra. But even then you're missing out on a few optional gcc warnings.



  • Not &dst. Just dst. dst as an rvalue is the address of the beginning of the array, which is why dst[0] is also *(dst + 0).



  • @Daid said:

    -Wall turns on all normal warnings, if you want fun, you turn on -Wextra. But even then you're missing out on a few optional gcc warnings.

    Thus the question, "what did they think the word 'all' meant?"

    Wouldn't -Wnormal do the normal warnings? Then -Wall do *all* of them?

    See, this is why I have trouble communicating with open source people-- open source people look at that and they're like, "oh no problem" and me, it drives me nuts.



  • @blakeyrat said:

    @Daid said:
    -Wall turns on all normal warnings, if you want fun, you turn on -Wextra. But even then you're missing out on a few optional gcc warnings.

    Thus the question, "what did they think the word 'all' meant?"

    Wouldn't -Wnormal do the normal warnings? Then -Wall do *all* of them?

    See, this is why I have trouble communicating with open source people-- open source people look at that and they're like, "oh no problem" and me, it drives me nuts.

    That pretty much sums up my entire experience in the IT industry. Everyone thinks they did the right thing as long as it works. I can't tell you how many conversations I've had with developers where I said "The method that enables a user account is named 'DisableUser'" and they replied "Don't worry about it, it's used properly and no one filed a bug". It's just as bad in corporations as it is in open source.

    If the entire IT industry suddenly switched to building bridges, I'd get rid of my car.


  • @realmerlyn said:

    Not &dst. Just dst
    If dst is an array, it doesn't matter - they're the same value. (This does not hold, of course, if dst is a pointer however.)



  • @blakeyrat said:

    open source people

    Unnerving concept, that.



  • I think the best one is Win32's CloseWindow. Which will hide a window, making it for all appearances, closed. What you actually need is DestroyWindow. An easy mistake to make with no obvious consequence beside resource leak.



  • @nexekho said:

    I think the best one is Win32's CloseWindow. Which will hide a window, making it for all appearances, closed. What you actually need is DestroyWindow. An easy mistake to make with no obvious consequence beside resource leak.

    Yeah, but that mistake can't bite you unless you've already made the fatal mistake of Win32 programming.

    (Although honestly that doesn't really strike me as wrong-- you can close a window without removing it from memory, that happens in tons of apps. Think about the Bookmarks window in a browser... there's nothing wrong with it existing in memory whether it's visible or not.)



  • @blakeyrat said:

    Wouldn't -Wnormal do the normal warnings? Then -Wall do all of them?

    It probably did do all of the normal things once. Then they invented a few more but didn't change -Wall because they didn't want to make the compiler incompatible with existing code. They could create a -Wall453 (say) option to include every warning that particular version supports, or they could reason that anyone who cares about code style that much will use lint anyway.

    In any case, I for one am disappointed that nexekho forgot -ansi -pedantic (to flag up all those horrid // comments, apart from anything else).

    @blakeyrat said:

    (Although honestly that doesn't really strike me as wrong-- you can
    close a window without removing it from memory, that happens in tons of
    apps.

    I was under the impression that this part of the thread was devoted to badly named functions, rather than ones which do things no sane person would ever need. As CloseWindow hides a window, it counts.



  • @__moz said:

    I was under the impression that this part of the thread was devoted to badly named functions, rather than ones which do things no sane person would ever need. As CloseWindow hides a window, it counts.

    Hiding a window is closing it, in GUI parlance. Is there a difference between the two?

    Even in programming parlance, Closing a SQL connection is distinct from Destroying it. So... I don't see the problem with that function name.



  • @blakeyrat said:

    Hiding a window is closing it, in GUI parlance. Is there a difference between the two?

    Even in programming parlance, Closing a SQL connection is distinct from Destroying it. So... I don't see the problem with that function name.

     

    OSX, afaik, is the only OS where closing a window does not exit the program. I'm not sure whether that's a UI fuckup of a twisted mind, or just really, really awkwardly implemented prefetch (as a running program can spawn its window faster, obviously).

    So yeah, CloseWindow intuitively should exit the program; destroy the window rather than hiding it, and since it does not do that, from that standpoint it's poorly named.

     



  • @dhromed said:

    So yeah, CloseWindow intuitively should exit the program; destroy the window rather than hiding it, and since it does not do that, from that standpoint it's poorly named.

    Because every computer program on Earth can have only one window ever? Or is that a really subtle troll I'm not getting?

    @dhromed said:

    OSX, afaik, is the only OS where closing a window does not exit the program. I'm not sure whether that's a UI fuckup of a twisted mind, or just really, really awkwardly implemented prefetch (as a running program can spawn its window faster, obviously).

    If you really care, it's a historical thing... Mac OS started life as a single-tasking OS (well... that's not quite true, but we'll ignore Desk Accessories for the moment to keep things simple), meaning that only one program could be run at a time, and the currently-running program had full control of your screen. This was really painful from System 7 to System 9, when Mac OS gained proper multitasking (that is, two programs could be visible at the same time), but didn't have good enough virtual memory technology to swap-out running-but-not-being-used processes-- so accidentally leaving a program open, which was super-easy, could also bring your system to a swapfest crawl. By the time OS X rolled around, the VM was good enough that it didn't really matter if you left programs open or not, so it stopped being a problem.



  • @blakeyrat said:

    @dhromed said:
    So yeah, CloseWindow intuitively should exit the program; destroy the window rather than hiding it, and since it does not do that, from that standpoint it's poorly named.

    Because every computer program on Earth can have only one window ever? Or is that a really subtle troll I'm not getting?

    You can quibble (rationalize), but if it were "open source types" who had named this, you'd be all over it. In the windows world, "close the window" usually means to quit the program (yes, yes, not always, but c'mon, that's what we typically think of). Even so, here's what MSDN says (link guaranteed for seconds after posting):
    @MSDN said:
    CloseWindow Function


    Minimizes (but does not destroy) the specified window.

    Hmm...minimize vs close. More twisty passages.



  • @blakeyrat said:

    @__moz said:
    I was under the impression that this part of the thread was devoted to badly named functions, rather than ones which do things no sane person would ever need. As CloseWindow hides a window, it counts.
    Hiding a window is closing it, in GUI parlance. Is there a difference between the two?

    Even in programming parlance, Closing a SQL connection is distinct from Destroying it. So... I don't see the problem with that function name.


    I expect no less of you. I shall have to demur nonetheless.

    In the context of inter-process communication, "close" always refers specifically to the connection. As the other side may close it for no clear reason, one wouldn't expect it to be any more destructive than necessary. In GUI programs, by contrast, closing usually implies losing the temporary data associated with whatever is being closed.

    There is a bit more variety in programming. In some contexts, closing a window may be destructive (as in Javascript), or not used at all (as in X11 and Curses). The Win32 API uses Close to refer to an easily reversed action. It's a perfectly sensible name if the main context in which multiple windows are created is in a file manager where each window represents a directory, and the windows have little temporary data of their own anyway.



  • @boomzilla said:

    You can quibble (rationalize), but if it were "open source types" who had named this, you'd be all over it. In the windows world, "close the window" usually means to quit the program (yes, yes, not always, but c'mon, that's what we typically think of).

    No it's not. Probably because I'm sane.

    Closing the window and quitting the program are two entirely different things. Quitting implies closing, but not vice-versa.

    @boomzilla said:

    Even so, here's what MSDN says (link guaranteed for seconds after posting):
    @MSDN said:
    CloseWindow Function


    Minimizes (but does not destroy) the specified window.

    Hmm...minimize vs close. More twisty passages.

    Ok, well I agree that's retarded.



  • @blakeyrat said:

    If you really care, it's a historical thing...
     

    +1 informative.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.