5 ms·

No this is very, very wrong. Consider: unsigned long addr_t = &x; This is not only completely legal ANSI C but is also idiomatic in kernel development.

pvg 16y ago
'generally'. It's the idea that you can easily mix up pointers and integers in C (and need to carefully remember types, etc) without getting told off by the compiler that's 'very, very wrong'. In your case, gcc will happily tell you: warning: initialization makes integer from pointer without a cast Without explicit casts, the compiler won't let you confuse pointers with integers without a warning or an error.
- Locke1689 16y ago
  Sorry, this post wasn't meant to be about the cast. You can cast it -- it's not that line itself that matters. It's that pointers and integers can take arbitrary values in C. After you do the cast is what really matters. In C you have to be aware of the semantics of your code at all times because the weak typing will not save you.
  - pvg 16y ago
    Well, to be honest, I really don't exactly know what we're talking about anymore. What the parent was saying is that you have to be super careful with the types of pointers and integers because C will let you use them interchangeably. This is obviously not true, despite the rain of inexplicable upvotes. He then has a pointer arithmetic example which is really not so much about typing but about understanding pointer arithmetic. Of course C will also let you treat pointers as integers and vice versa, especially if you explicitly tell it to, by casts. But in the general case, it will whine and, in fact, reducing unnecessary whining is one of the reasons to not go hog-wild with useless typedefs. I'm not sure how we got here, I think one person here doesn't know C very well and the rest of us got into a little and completely tangential C nerdfest.
    - Locke1689 16y ago
      Of course C will also let you treat pointers as integers and vice versa, especially if you explicitly tell it to, by casts. But in the general case, it will whine and, in fact, reducing unnecessary whining is one of the reasons to not go hog-wild with useless typedefs. I'm not sure how we got here, I think one person here doesn't know C very well and the rest of us got into a little and completely tangential C nerdfest. Hmm that's fair. I also think I started entering kernel-dev mode where you have to carefully watch everything that you do, whereas most people probably have C experience with the benefit of things like the C standard library. For whatever it's worth, I was seeking to reference the idiom where you store an address as an integer in order to do some hardware operations. You have to keep semantic knowledge of that integer as really being a pointer even though it's, for the moment, stored as an integer. In cases like this the C compiler is no help whatsoever.
ori_b 16y ago
Sorry, what? $ cat test.c int x; unsigned long addr_t = &x; $ cc test.c test.c:2: warning: initialization makes integer from pointer without a cast
- scott_s 16y ago
  He's correct that it's legal ANSI C, but pvg is also correct in pointing out that compilers will warn you. (And being legal ANSI C is not necessarily the same thing as being portable.)
  - Locke1689 16y ago
    Right but it's not about being portable in kernel development -- the entire thing you're building is in and of itself nonportable.
    - scott_s 16y ago
      Err, not really. You should be as portable as possible across different architectures. For example, on a 32-bit machine you can get away with using an unsigned int to represent an address, but that will break on a 64-bit machine. The fact that the Linux kernel works on such disparate architectures also works against your point.
      - Locke1689 16y ago
        No it's not portable C. We replicate code for different architectures. There are portable sections, true, but the entire kernel isn't portable. Look in the source directory to find the amd64/x86/ARM specific code. If you know how to make __asm__ __volatile__(...) portable I'd love to hear it.
        scott_s 16y ago
        We may be in violent agreement. Large swaths of the kernel can be portable, and you should code them as such. Of course architecture specific parts of the kernel will not be portable.

pvg 16y ago

'generally'. It's the idea that you can easily mix up pointers and integers in C (and need to carefully remember types, etc) without getting told off by the compiler that's 'very, very wrong'. In your case, gcc will happily tell you: warning: initialization makes integer from pointer without a cast Without explicit casts, the compiler won't let you confuse pointers with integers without a warning or an error.

Locke1689 16y ago
Sorry, this post wasn't meant to be about the cast. You can cast it -- it's not that line itself that matters. It's that pointers and integers can take arbitrary values in C. After you do the cast is what really matters. In C you have to be aware of the semantics of your code at all times because the weak typing will not save you.
- pvg 16y ago
  Well, to be honest, I really don't exactly know what we're talking about anymore. What the parent was saying is that you have to be super careful with the types of pointers and integers because C will let you use them interchangeably. This is obviously not true, despite the rain of inexplicable upvotes. He then has a pointer arithmetic example which is really not so much about typing but about understanding pointer arithmetic. Of course C will also let you treat pointers as integers and vice versa, especially if you explicitly tell it to, by casts. But in the general case, it will whine and, in fact, reducing unnecessary whining is one of the reasons to not go hog-wild with useless typedefs. I'm not sure how we got here, I think one person here doesn't know C very well and the rest of us got into a little and completely tangential C nerdfest.
  - Locke1689 16y ago
    Of course C will also let you treat pointers as integers and vice versa, especially if you explicitly tell it to, by casts. But in the general case, it will whine and, in fact, reducing unnecessary whining is one of the reasons to not go hog-wild with useless typedefs. I'm not sure how we got here, I think one person here doesn't know C very well and the rest of us got into a little and completely tangential C nerdfest. Hmm that's fair. I also think I started entering kernel-dev mode where you have to carefully watch everything that you do, whereas most people probably have C experience with the benefit of things like the C standard library. For whatever it's worth, I was seeking to reference the idiom where you store an address as an integer in order to do some hardware operations. You have to keep semantic knowledge of that integer as really being a pointer even though it's, for the moment, stored as an integer. In cases like this the C compiler is no help whatsoever.

ori_b 16y ago

Sorry, what? $ cat test.c int x; unsigned long addr_t = &x; $ cc test.c test.c:2: warning: initialization makes integer from pointer without a cast

scott_s 16y ago
He's correct that it's legal ANSI C, but pvg is also correct in pointing out that compilers will warn you. (And being legal ANSI C is not necessarily the same thing as being portable.)
- Locke1689 16y ago
  Right but it's not about being portable in kernel development -- the entire thing you're building is in and of itself nonportable.
  - scott_s 16y ago
    Err, not really. You should be as portable as possible across different architectures. For example, on a 32-bit machine you can get away with using an unsigned int to represent an address, but that will break on a 64-bit machine. The fact that the Linux kernel works on such disparate architectures also works against your point.
    - Locke1689 16y ago
      No it's not portable C. We replicate code for different architectures. There are portable sections, true, but the entire kernel isn't portable. Look in the source directory to find the amd64/x86/ARM specific code. If you know how to make __asm__ __volatile__(...) portable I'd love to hear it.
      - scott_s 16y ago
        We may be in violent agreement. Large swaths of the kernel can be portable, and you should code them as such. Of course architecture specific parts of the kernel will not be portable.