The Big Programming Thread - Page 865

On March 29 2017 23:02 TMG26 wrote:


It's also recommended in older C standards.

On March 29 2017 23:46 Biolunar wrote:

Definitely not. In old C you can use functions without providing a declaration, in which case a return value of ‘int’ is assumed. So let’s say you forget to include stdlib.h but you use malloc. The complier then assumes there is a function ‘int malloc()’ somewhere. Now you cast that returned int into your pointer type and use it. Great. You just traded a compile time error in for a runtime error. Don’t cast malloc.

On March 30 2017 04:53 BluzMan wrote:


Ermm, I'm curious how the linker would assemble the executable without a function definition?

On March 30 2017 05:34 Cyx. wrote:

It has a definition for standard library functions since it links against the stdlib by default. Most compilers will complain about 'implicit declaration of malloc' or something like that but they'll generally allow it unless you have warnings way up. Although I don't see how this trades a compile-time error for a runtime error... either way, you just get a warning about the implicit definition, with maybe an additional warning about casting a pointer to integer.

e: also, I've never seen casting malloc recommended in C, it's required if you use malloc in C++ (which you just shouldn't do) but every C programmer I know says 'don't cast malloc'.

On March 30 2017 19:34 Manit0u wrote:
PGSQL question:

Tables

A >---< B >---< C

>---< is a many-to-many relation with an intermediate table containing
ids of referenced table rows

What I need

SELECT DISTINCT C.id WHERE [A_B.b_ids] @> [C_B.b_ids] 

Basically, I need all C's whose related Bs are all in A's related Bs (for a single A) - a matching subset if you will. Any idea how I should construct this query?

On March 30 2017 19:54 berated- wrote:


Is that not just distinct c from c join b join a, through the intermediate tables? Is it too large to do so?

Or just intermediate join intermediate join c.

SELECT res.id
FROM (
    SELECT C.id, array_agg(C_B.b_id) AS b_ids
    FROM "C" INNER JOIN "C_B" ON "C_B"."c_id" = "C"."id"
    GROUP BY "C"."id"
) AS res
WHERE (res.b_ids <@ ARRAY[21,84,57,58,8,40,34,59,38,71,35,67,48,62,92,99,12,14,88,5,53])

On March 30 2017 05:34 Cyx. wrote:

It has a definition for standard library functions since it links against the stdlib by default. Most compilers will complain about 'implicit declaration of malloc' or something like that but they'll generally allow it unless you have warnings way up. Although I don't see how this trades a compile-time error for a runtime error... either way, you just get a warning about the implicit definition, with maybe an additional warning about casting a pointer to integer.

e: also, I've never seen casting malloc recommended in C, it's required if you use malloc in C++ (which you just shouldn't do) but every C programmer I know says 'don't cast malloc'.

On March 30 2017 23:31 meadbert wrote:
Regarding casting malloc. I use gcc 5.3.1 with -Wall and it will still warn if I do not cast malloc.

On March 30 2017 23:31 meadbert wrote:
int *heap = malloc(size*sizeof(int)) - 1; // <--- THIS IS A BUG!!!

On March 31 2017 02:15 Biolunar wrote:

This is hard for me to believe. void* -> T* is an implicit lossless conversion that should compile without warning. Did you compile it as C++? Does not warn me with -Wall -Wextra on gcc nor on clang with -Weverything.


Yes that’s a bug, because it does not compile malloc returns void* and void* does not allow pointer arithmetic. As you stated correctly you need to cast it before you can do some arithmetic on the return value (or save the value and decrement it afterwards).

#include <stdlib.h>
#include <stdio.h>

int main(void)
{
    void *c = malloc(10*sizeof(*c)) - 1;
    int *i = c + 3;
    int *j = c;
    int d = i - j;
    
    printf("%d\n", d);    
    return 0;
}

On March 31 2017 04:10 meadbert wrote:
I just tested this code:

#include <stdlib.h>
#include <stdio.h>

int main(void)
{
    void *c = malloc(10*sizeof(*c)) - 1;
    int *i = c + 3;
    int *j = c;
    int d = i - j;
    
    printf("%d\n", d);    
    return 0;
}

I used -Wall and -Wextra.

I got no warnings. So it appears that the cast from void* to int* does not generate a warning, but also the pointer subtraction on void* worked just fine with not so much as a warning.

EDIT: I just did some research and pointer addition on void* is illegal in both C and C++, but GCC apparently allows for it which explains the results that I saw.

man gcc
-Wpointer-arith
Warn about anything that depends on the "size of" a function type or of "void". GNU C assigns these types a size
of 1, for convenience in calculations with "void *" pointers and pointers to functions. In C++, warn also when an
arithmetic operation involves "NULL". This warning is also enabled by -Wpedantic.

On March 31 2017 05:15 travis wrote:
I have a feeling this thread is gonna really blow up over the summer when I take Intro to Algorithms.