Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: C Experts Panel – Ask us anything about C

news.ycombinator.com

Post reply on HN
Print view View original

901–910 of 978 posts

Re: Tell HN: C Experts Panel – Ask us anything about C

#901

Post by flatfinger »

mpweiher wrote: post #891
a1369209993 wrote: post #806

Earlier quoted context omitted.

> ["]I can use that information!" Yes, that is a perfect example of buggy compiler handling of undefined behaviour. A non-buggy compiler would either behave in a manner chacteristic of the environment (ie read address array+i), ignore the situation entirely (which also results in reading array+i), or (preferably) issue a error to the effect of "possible array access out of bounds, suggest 'assert(i<10);' here".

Very well put (deliberately using the exact terminology used in the standard)! Can we just make that binding again? After all, it used to be. It should be obvious to compiler writers what the intention of the standard is, because it says so in the dang text , but since this was downgraded to a note and you are technically not in violation if you do something different, everyone now acts as if doing the exact opposite…

> It should be obvious to compiler writers what the intention of the standard is, because it says so in the dang text, but since this was downgraded to a note and you are technically not in violation if you do something different, everyone now acts as if doing the exact opposite of what is written there is somehow OK.

Note that a compiler could be incapable of processing any useful programs whatsoever, and yet still be a "conforming C implementation" if it is capable of processing a deliberately contrived and useless program that exercises the Standard's translation limits. The authors of the Standard even acknowledge that possibility in the Rationale.

The problem is that the authors of the Standard recognized that anyone seeking to sell compilers would treat Undefined Behavior as an invitation to behave in whatever fashion would best meet their customers' needs, but failed to consider that a moderately-decent freely distributable compiler could become popular as a result of being freely distributable without its maintainers having to respect its users.

Re: Tell HN: C Experts Panel – Ask us anything about C

#902

Post by DerekL »

modeless wrote: post #521

Can you do anything to push Microsoft to implement recent C standards? Their failure to fully implement even C99 in Visual Studio is holding the language back.

My understanding is that Microsoft doesn't want to support C, and the only reason Visual Studio supports C at all is for legacy code. Also, you can use 3rd-party compilers with Visual Studio.

Really, anyone writing C nowadays should ignore Microsoft's compiler, and tell Visual Studio users to install Clang.

Re: Tell HN: C Experts Panel – Ask us anything about C

#903

Post by defectbydesign »

DougGwyn wrote: post #536
tzs wrote: post #466

If an old timer who used to be good with C wanted to use C again, would they have to learn a whole bunch of weird new stuff or could they pretty much use it like they did back in the stone age (i.e., the 20th century)? Back in the '80s and '90s I was pretty good at C. I don't think there was anything about the language or the compilers than that I did not understand. I used C to write real time multitasking kernels f…

The main editing needed to bring "old C" source code up to snuff using a "modern C" compiler is to make sure that the standard header-defined types are used. No more assuming that a lot of things are, by default, int type. A second, related editing pass is to make sure all functions are declared as prototypes, no longer K&R style; K&R style is slated to be deprecated by the next version of the Standard. (There are so…

So the ISO committee breaks the backward compatibility of C in behalf of modernity... but there is C++ guys!

A little effort and you could make C deprecated. ;-)

This makes me think that there are as many C++ gurus than Go(ogle) gurus who want to kill C to be the new Java which brings you a bad coffee from a dirty kitchen.

Re: Tell HN: C Experts Panel – Ask us anything about C

#904

Post by souprock »

AaronBallman wrote: post #108
emilfihlman wrote: post #98

Earlier quoted context omitted.

>and how to handle format specifiers for it is part of those discussions, so we are considering some changes in this area. Please, please, please pick short and descriptive format specifiers, like %[suf]\d+, ie s64 v=somenumber; printf("%s64\n", v); _ExtInt(N) and PRIx64 etc look absolutely horrid. u?int\d+_t are also really bad, it would be great to have just [suf]\d+ as types, where \d+ is 8, 16, 32, 64 for [us] an…

> Please, please, please pick short and descriptive format specifiers, like %[su]\d+, ie That's my personal preference as well. Using the PRI macros always makes me feel sad. > Say like VLAs but structures with members that are dynamically defined and used. Ah, no, I don't recall any proposals along those lines. It's an interesting idea, and I'd be curious what the runtime performance characteristics would be vs what…

First, I agree on the PRI macros. I refuse to use them.

Stucture member access by name is useful. It's slow, but it doesn't affect code that isn't using the feature. The worst runtime issue is that the runtime support requirement grows. For example, libgcc would gain a few functions.

We can do it today with awkward code, sometimes involving hacks that are outside the C language. Implementations vary by how much they hide what is going on. When I implemented libproc.so for Linux, I made two implementations. The high-performance one used a perfect hash table that was generated by gperf and then hand-edited. Name look-up would do the hash, index into an array of structs, compare the name for a match, and then use gcc's computed goto extension to jump to code that would handle the struct member. Had I not been also parsing the data in various distinct ways, I might have used an offsetof() macro to let generic code fill in the struct fields. The other implementation I made, with lower performance, used bsearch on a sorted array.

Dynamically defined struct members are also useful, but even slower and with even more overhead. Again though, I don't think that other code would be affected beyond the growth of the compiler's libgcc equivalent.

Seeing what I just wrote above, the computed goto extension is more important. It's great for any kind of table look-up that needs code to run. Emulators use it a lot, and would use it much more if it were in the C standard.

Re: Tell HN: C Experts Panel – Ask us anything about C

#905

Post by defectbydesign »

defectbydesign wrote: post #785

I am sorry to tell this but the C programming language doesn't need anymore the ISO committee since it introduced non de facto standard features such as VLA. For reference I still use The C Programming Language by KERNIGHAN/RITCHIE and The Standard C Library by PLAUGER. In my view what programmers need the most is good practices rather than any syntactic sugar. I prefer C rather than any other programming language fo…

No answer but -2 points.

It seems cowards don't have any argument. :-)

Re: Tell HN: C Experts Panel – Ask us anything about C

#906

Post by flatfinger »

a1369209993 wrote: post #897
flatfinger wrote: post #894

Earlier quoted context omitted.

The amount of effort for a compiler to process optimally all 72 variations of "read/write a signed/unsigned 2/4/8-byte big/little-endian value from an address that is aligned on a 1/2/4/8-byte boundary" would be less than the amount of effort required to generate efficient machine code for all the ways that user code might attempt to perform such an operation in portable fashion. Such operations would have platform-i…

I'm not disagreeing, just showing code to illustrate why memcpy doesn't work for this. Although I do disagree that writing a signed value is useful - you can eliminate 18 of those variations with a single intmax_t-to-twos-complement-uintmax_t function (if you drop undefined behaviour for (unsigned foo_t)some_signed_foo this becomes a no-op). A set of sext_uintN functions would also eliminate 18 read-signed versions.…

> Although I do disagree that writing a signed value is useful

Although the Standard defines the behavior of signed-to-unsigned conversion in a way that would yield the same bit pattern as a two's-complement signed number, some compilers will issue warnings if a signed value is implicitly coerced to unsigned. Adding the extra 18 forms would generally require nothing more than defining an extra 24 macros, which seems like a reasonable way to prevent such issues.

Re: Tell HN: C Experts Panel – Ask us anything about C

#908

Post by benibela »

orenht wrote: post #876
benibela wrote: post #875

Earlier quoted context omitted.

Why not typedef struct {uint8_t *data, dataend} ? Makes it easier to take subranges out of it

should be typedef struct {uint8_t *data, *dataend} if I'm not mistaken :)

Right. I always think the pointer declaration is part of the type. (that is why I do not use C. Is there really a good reason for this C syntax?)

Re: Tell HN: C Experts Panel – Ask us anything about C

#909

Post by flatfinger »

rseacord wrote: post #683
_kst_ wrote: post #512

Earlier quoted context omitted.

"based on pointer providence" I think you meant "provenance" (mentioning it for the sake of anyone who wants to search for it).

Yes, my mistake--I was thinking of Rhode Island. I wrote a short bit about this at https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... if anyone is interested.

What makes pointer provenance really great is that clang and gcc will treat that pointers that are observed to have the same address as freely interchangeable, even if their provenance is different. Clang sometimes even goes so far with that concept that even uintptr_t comparisons won't help.

    extern int x[],y[];
    int test(int i)
    {
        y[0] = 1;
        if ((uintptr_t)(x+5) == (uintptr_t)(y+i))
            y[i] = 2;
        return y[0];
    }
If this function is invoked with i==0, it should be possible for y[0] and the return value to both be 1, or both be 2. If x has five elements, however, and y immediately follows it, clang's generated code will set y[0] to 2 and yet return 1. Cool, eh?

Re: Tell HN: C Experts Panel – Ask us anything about C

#910

Post by fkeeal »

gbear605 wrote: post #431
dooglius wrote: post #286

Earlier quoted context omitted.

>In your example there's no guarantee that the length will be accurate, or that the data hasn't been modified independently elsewhere in the program. And having a special data-and-length type would make these guarantees... how? You're ultimately going to need to be able to create these objects from bare data and length somehow, so it's a case of garbage-in-garbage-out.

Declaring it with a custom struct: int raw_arr[4] = {0,0,0,0}; struct SmartArray arr; arr.length = 4; arr.val = raw_arr; some_function(arr); Smart declaration with custom type: (assume that they'll come up with a good syntax) smart_int_arr arr[4] = {0,0,0,0}; some_function(arr); With the custom struct, it requires the number `4` to be typed twice manually, while in the second it only needs a single input.

You actually never need to specify the size explicitly in C.

Here are some other ways to declare your struct without needing as much boiler plate per declaration.

    #define MAKE_SMARTARRAY(_smartarr, _array) \
            do {\
                _smartarr.val = (_array);\
                _smartarr.len = sizeof((_array))/sizeof((_array[0]));\
            }while(0)
    
    struct SmartArray
    {
        int *val;
        int len;
    };
    
    int main()
    {
        int array[] = {0,0,0,0};
        
        struct SmartArray arr = {.val = array, 
                                    .len = sizeof(array)/sizeof(array[0])};
        struct SmartArray arr2;
        struct SmartArray arr3;
        
        MAKE_SMARTARRAY(arr2, ((int[]){5,6,7,8}));
        MAKE_SMARTARRAY(arr3, array);
    
        return 0;
    }
Post reply on HN